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(57) Abstract 

A tokenless idencific.itior: system .ind method are principally based on a correlative comparison of a unique biometrics sample, such 
as :t finger print or voice recording, gaDiered directly from the person of an unknown user, with an authenticated biometrics sample of 
the same type obtained and stored previously (1). It can be networked to act as a full or pjrt'ta; intermediary between other mdepentkm 
computer systems (3), or maybe the sole computer systems earning out all necessary executions. 
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Background 

The use of tokens and credit cards in today's financial world 
is pervasive, A token wouid be any manimate object which confers a 
capability to the individual presenting the object- Remote access of every 
20 financial account is through the use of tokens or plastic cards. Whether 

buying groceries with debit cards or consumer goods with credit cards, at 
the heart of that transaction is a money transfer enabled by a token, which 
acts to identify an individual and the financial account he is accessing. 

The reason for the migration from metal coins to plastic 
25 cards is simple and straightforward: access to money in this money transfer 

system is vastly safer and more convenient for both merchants and 
consumers than handling large quantities of coins and notes. 

Unfortunately, current technology in combination with this 
convenient token-based money transfer system results in a system that is 
30 prone to theft and fraud. 

As verification of user identity is based solely on data placed 
on the token, which can be easily reproduced and transferred between 
individuals, such security must rely on both the diligence and the iuck of 
the authorized user and merchant in mamtaking this information as 
35 proprietary. However, by their very nature, tokens do not have a very 

strong connection with the individual Identification of the rightful owner 
of the token through the token is tenuous at best. This is easily 
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demonstrated by the fact that individuals other than the rkfatfui owners of 
the tokens have been using these tokens to defraud merchants and other 
consumer goods suppliers. 

The mammoth expansion of the consumer credit industry 
dunng the 1980s brought with it large profits for issuers, and newfound 
convemence for consumers. However, as consumer credit became easier 
for consumers to acquire, it also became a target for criminals. Much as the 
mobility of the automobile ied to a rash of bank robberies in the iate 1920's 
and early 1 930's, so too did the ubiquity of consumer credit lead to vastly 
increased opponunities for criminals. 

Initially, the banking industry was willing to accent a certain 
amount of loss due to fraud, passing the cost on to the consumer 
However, as criminals became more organized, more technically adept and 
as credit retail stations began to be manned by people who were more and 
more poorly trained in credit card security matters, the rate of increase of 
fraud losses skyrocketed. The staggering statistics on fraud and cost of 
prevents steps, has forced the credit card companies in particular, to look 
for other solutions to the problem. 

Fraud losses in the credit card industry stem from many 
different areas due to the highly vulnerable nature of the system, but they 
are mainly due to either lost, stolen, or counterfeit cards. Credit cards " 
operate without the use of a personal identification code (PIC), therefore a 
lost creoit card can be mrned into cash if the card falls into the wrong 
hands. While theft of a token constitutes the majority of fraud in the 
system, the use of counterfeit credit cards has been on the nse. Counterfeit 
credtt cards are manufactured by a more technically sophisticated criminal 
by acqumag a cardholder's valid account number and then producing a 
counterfeit card using that valid number. The counterfeiter encodes the 
magnetic strip, and embosses the counterfeit plastic card with the account 
number. The card is then presented to merchants and charged up to the 
rightful cardholder's account. Another form of loss is by a criminal 
merchant who surreptitiously obtains the cardholder's account number. 
Yet another type of fraud is committed by the authorized cardholder when 
the token is used for making purchases and thereafter a claim is made that 
tne token was either lost or stolen. It is estimated that losses due to all 
types of fraud exceeds S950 million dollars annually 
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Generally, debit cards are used in conjunction with a 
personal identification code (PIC). Counterfeiting a debit card is more 
diMcuit as the criminal must acquire not only the account number, but also 
the PIC, and then manufacture the card as in the credit card example 
However, various strategies have been used to obtain PICs from unwary 
cardholders; these range from Trojan horse automated teller machines, or 
ATMs, m shopping mails that dispense cash but record the PIC to 
merchant point of sale devices that aiso record the PIC, to individuals with 
otnoculars that watch cardholders enter PICs at ATMs. The subsequently 
manufactured counterfeit debit cards are then used in various ATM 
machines until the unlucky account is emptied. 

The financial industry is weii aware of the trends in fraud 
expense, and is constantly taking steps to improve the security of the card 
Thus traud and theft of token have an indirect impact on the cost to the 
systetn. 

Card blanks are manufactured under very tight security 
Then they are mdrviduafced with the account number, expiration date and 
are then mailed to the cardholder. Manu&cturing and distributing the card 
alone costs the industry approximately one billion dollars annually The 
standard card costs the financial industry $2 for each, but only $0.30 of this 
$2 is associated with actual manufacturing cost. 

Over the last ten years, the industry has altered the tokens 
because of counterfeiting fraud, without any fundamental changes in the 
use of the credit transaction system. The remedy has been mostly 
administrative changes such as having customers call the issuer to activate 
their card. Other changes include addition of a hologram, a picture ID or 
an unproved signature area. These type of changes in particular, are an 
ind lC at,on that the systems susceptibility to fraud is due to lack of true 
identification of the individual. It is estimated that this could double the 
manufacturing cost to two billion dollars annually. 

In the near future, the banking industry expects to move to 
an even more expensive card, called a "smart card". Smart cards contain as 
much computing power as did some of the first home computers. Current 
cost projections for a first-generation smart card is estimated at 
approximately S3 .50, not including distribution costs, which is significantly 
higher than the $0.30 plastic card blank. 
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This significant increase in cose has forced the industry to 
iook for new ways of using the power in the smart card in addition to 
simple transaction authorization. It is envisioned that in addition to storing 
credit and debit account numbers, smart cards may also store phone 
numbers, frequent flyer miles, coupons obtained from stores, a transaction 
history, electronic cash usable at tollbooths and on pubic transit systems, 
as well as the customer's name, vital statistics, and perhaps even medical 
records. Clearly, the financial industry trend is to farther establish use of 
tokens. 

The side effect of increasing the capabilities of the smart 
card is centralization of functions. The flip side of increased functionality is 
increased vulnerability. Given the number of functions that the smart card 
will be performing, the toss or damage of this monster card will be 
excruciatingly inconvenient for the cardholder. Being without such a card 
will financiaiiy incapacitate the cardholder until it is replaced. Additionally, 
losing a card full of electronic cash will also result in a real financial toss as 
well. Furthermore, ability of counterfeiters to one day copy a smartcard is 
not addressed. 

Urtfortunately, because of the projected concentration of 
functions onto the smart card, the cardholder is left more vulnerable to the 
loss or destruction of the card itself Thus, after spending vast sums of 
money, the resulting system will be more secure, but threatens to levy 
heavier and heavier penalties for destruction or loss of this card on the 
consumer. 

The financial industry recognizes the security issues associated 
with smartcards, and efforts are currently underway to make each plastic 
card difficult to counterfeit. Billions of dollars win be spent in the next five 
years in attempts to make plastic ever more secure. To date, the consumer 
financial transaction industry has had a simple equation to balance; in order 
to reduce fraud, the cost of the card must increase. 

in addition to and associated with the pervasiveness of 
electronic financial transactions, there is now the widespread use of 
electronic facsimiles, electronic mail messages and similar electronic 
communications. Similar to the problem of lack of proper identification of 
individuals for financial transactions is the problem of lack of proper 
identification of individuals for electronic transmissions. The ease and 
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speed of electronic communication, and its low cost compared to 
conventional mail, has made it a method of choice tor communication 
between individuals and businesses alike. This type of communicanon has 
expanded greatly and is expected to continue to expand However 
millions of electronic messages such as facsimiles and electronic mail (or 
"E-mail" or "email") messages are sent without knowing whether they 
amve at their true destination or whether a certain individual actually sent 
or received thai electronic message. Furthermore, there is no way to verify 
the identify the individual who sent or who received an electronic message. 

Recently, various attempts have been made to overcome 
problems inherent in the token and code secunty system. One major focus 
has been to encrypt, variable or otherwise modify the PIC to make it 
more difficult for an unauthorised user to carry out more than one 
transacuon, largely by focusing on manipulation of the PIC to make such 
code more fraud resistant. A variety of approaches have been jested, 
such as mtroducing an algorithm that varies the PIC in a predictable way 
known only to the user, thereby requiring a different PIC code for each 
subsequent accessing of an account. For example, the PIC code can be 
varied and made specific to the calendar day or date of the access attempt 
In yet another approach, a time-variable element is introduced to generate 
a non-predictable personal identification code that is revealed only to an 
authored user at the time of access. Although more resistant to fraud that 
systems incorporating non-variable codes, such an approach is not virtually 
fraud-proof because it stiii relies on data that is not uniquely and 
irreproduciblv personal to the authorised user. Furthermore, such svstems 
further inconvenience consumers that already have trouble rememberine 
constant codes, much less variable ones. Examples of these approaches^ 
disclosed in United States Patents 4,837,422 to Dethioffct ai ■ 4 99% 279 
to Weiss; 5,168,520 to Weiss; 5,251,259 to Mosley; 5,239,538 to Panillo- 
5,276,3 14 to Martino et at.; and 5,343,529 to Goldfine et al. ail of which 
are incorporated herein by reference. 

More recently, some have turned their attention from the use 0 f 
personal identification codes to the use of unique biometrics as the basis of 
identity verification, and ultimately computer access. In this apnroach, 
authenticated biometrics are recorded from a user of known identity and 
stored for future reference on a token. In every subsequent access attempt 
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the user is required to enter physicaiJy the requested biometrics, which are 
then compared to the authenticated biometrics on the token to determine if 
the two match in order to verify user identity. Because the biometrics are 
uniquely personal to the user and because the act of physically enterins the 
biometrics are virtually irreprodurible, a match is putative of actual 
identity, thereby decreasing the risk of fraud. Various biometrics have been 
suggested, such as finger prints, hand prints, voice prints, retinal images, 
handwriting samples and the like. However, because the biometrics are 
generally stored in electronic (and thus reproducible) form on a token and 
because the comparison and verification process is not isolated from the 
hardware and software directly used by the individual attempting access, a 
significant risk of fraudulent access still exists. Examples of this approach 
£0 system security are described in United States Patents 4,821 ,118 to 
Lafreniere; 4,993,068 to Piosenka et al.; 4,995,086 to LiUey et al .; 
5,054,089 to Uchida et ai.; 5,095,194 to Barbaneli; 5,109,427 to Yang; 
5,109,428 to Igaki et al.; 5, 144,680 to Kobayashi et al.; 5,146,102 to ' 
Higuchi et al. ; 5,180,901 to Hiramatsu; 5,210,588 to Lee; 5,210,797 to 
Usui et al.; 5,222,152 to Fishbine et al.; 5,230,025 to Fishbine et ai.; 
5,241,606 to Horie; 5,265, 162 to Bush et al.; 5,321,242 to Heath, Jr.; 
5,325,442 to Kna pp; 5,351,303 to Wiiimore, all of which are incorporated 
herein by reference. 

As will be appreciated from the foregoing discussion, a dynamic 
but unavoidable tension arises in attempting to design a security system 
that is highly fraud resistant, but nevertheless easy and convenient for the 
consumer to use. Unfortunately, none of the above-dtsciosed proposed 
improvements to the token and code system adequately address, much less 
attempt to balance, this tension. Such systems generally store the 
authenticated biometrics in electronic form directly on the token that can 
presumably be copied. Further, such systems do not adequately isolate the 
identity verification process from tampering by someone attempting to gain 
unauthorized access. 

An example of token-based security system which relies on a 
biometrics of a user can be found in United States Patent 5,280.52? to 
Guilman et al. In Guliraan's system, the user must carry and present a 
credit card sized token (referred to as a biometrics security apparatus) 
containing a microchip in which is recorded characteristics of the 
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authorized users voice, in order to initiate the access procedure, the user 
must insert the token mto a terminal such as an ATM, and then speak into 
tne tenmnai to provide a biometrics input for comparison with an 
authenticated input stored in the microchip of the presented token. The 
proems of identity verification is generally not isolated from potential 
rampenng by one attempting unauthorized access. If a match is found the 
remote terminal may then signal the host computer that access should be 
permitted, or may prompt the user for an additional code, such as a PIN 
«» stored on the token), before sending the necessary verifkauon signal 
to the host computer. 

Although Guilman's rehance of comparison of stored and input 
mometnes potentially reduces the risk of unauthonzed access as compared 
to numeric codes, Cullman's use of the token as the repository for the 
authenttcating data combined with Guilman's failure to isolate the identity 
venncauon process from the possibility of tampering greatly diminishesly 
improvement to fraud resistance resulting from the replacement of a 
numenc code with a biometrics. Further, the system remains somewhat 
cumbersome and inconvenient to use because it too requires the 
presentation of a token in order to initiate an access request. 

Almost uniformly, patents that disclose token-based systems 
teach away from biometrics recognition without the use of tokens 
Reasons cited for such teachings range from storage requirements for 
fcometnes recognition systems to significant time lapses in identification of 
a large number of individuals, even for the most powerful compters 
In view of the foregoing, there has long been a need for a 
computer access system that is highly fraud-resistant, practical and 
efficient for the user to operate and carry out electronic transactions and 
transmissions expeditiously. 

There is also a need for a computer system that is completely 
tokemess and that is capable of verifying a users personal identity based 
solely upon a personal ldemification code ^ ^ fa ^ ^ 

physicaiiv personal to an authorized user, as opposed to verifying an 
^dual's possession of any physical objects that can be fr ee | v transferred 
between different individuals. Such biometrics must be easiiy and 
intrusively obtained; must be easy and cost-effective to store and to 
analyze; and must not unduly invade the user's privacy rights 
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A further need in computer access system design is user 
commence. It is highly desirabJe &r a consumer tQ ^ tQ ^ ^ 
system spontaneously, particularly when unexpected seeds arise, with a 
mmmm of effort. la p»ticulax, there is a need for a system that areatiy 
reduces or eliminates the need to memorize numerous or cumbersome 
codes, and that eliminates the need to possess, carry, and present a 
propnetary object in order to initiate an access request. 

Such systems must be simple to operate, accurate and reliable 
There is also a need for a computer access system that can allow a user to 
access multiple accounts and procure all services authorized to the user, 
and carry out transactions in and between aU financial accounts, make point 
at purchase payments, receive various services, etc. 

There is &rther a great need for a computer access system that 
affords an authorized user the ability to alert authorities that a third parry is 
coercing the user to request access without the third party being aware that 
an alert has been generated. There is aiso a need for a system that is 
aesthete, able to effiw. unknown to the coercing third party, temporary 
restrictions on the types and amounts of transactions that can be 
undertaken once access is granted. 

Furthermore, the computer system must be affordable and 
flexible enough to be opmtively compatible with eating networks having 
a vanery of electronic transaction and transmission devices and svstem 
configurations. 

Finally, there is a need for secured sending and receipt of 
electronic mail messages and electronic facsimiles, where content of the 
electronic message is protected from disclosure to unauthorized 
mdmduals, and the identity of the sender or recipient can be obtained with 
a high degree of certainty. 

Summary of the Invention 

The present invention satisfies these needs bv providina an 
improved identitkauon system for detennining an individual's idenrirv from 
a comparison of an individual's biometrics sample and personal 
identification code gathered during a bid step with biometrics sample and 
personal Hfenaficarion code for that individual gathered durine a 
registration step and stored at a remote site wherein there is adata 
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processing center. The invention comprises a computer network host 
system with means for comparing the entered biometrics sample and 
pmonai identification code, and is equipped with various data bases and 
memory modules. Furthermore, the invention is provided with biometrics 
and persona! identification code input apparatus and ienmnals for entering 
data to provide information for execution of the requested transactions and 
mmmmous by the host system once the identity of the individual is 
detemnned. The invention is also provided with means for connecting the 
host system with the terminal and the biometrics input apparatus. 

The computer also has means for execution of various 
ttMsacnom and transmission in addition to traditional storing of and 
modification of data. Additional the computer can output the evaluation 
of the biometrics- WC ("personal identification code") comparison, and the 
determmattoo of an identification evaluation, or status of any execution of 
tnwacuoo. or transmissions. Furthermore, the computer system notifies 
and authenticates to the individual being identified that the computer 
system was accessed, by returning to the individual a private code which 
was previously selected by that individual during the registration step. 

Preferably, the computer system is protected from electronic 
eavesdropping and electronic intrusion and viruses. Further, the devices 
used by the computer for gathering biometric samples and personal 
idabficm codes would comprise: a) at least one biometric input device 
for gathemg biometric samples, which would have a hardware and a 
software component; b) at least one tenmnal device that is functionally 
partly or &liy integrated with the biometric input means for input of and 
appending ancillary information; c) at least one data entry device for input 
of a personal identification code whereby this data entry device is 
integrated either with the biometric mput device or the terminal device 
and, d) a means for interconnectmg the biometric input device, data Jay 
device and the terminal. The tenninal device also has at least one display 
devtce for displaying data and information. For additional security the 
computer system uniquely identifies the biometric input apparatus, and the 
counter party or merchant through a counter party or merchant 
identification code relating to the terminal that is connected to the 
biometric input device. It is also preferred that the biometric input 
apparatus be secured from physical and electronic tampering, and that » 
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case of physical breach of the device, means be employed to physically 
and/or electronically destroy components within the apparatus and/or erase 
critical data from the device's memory modules. 

In addition, the biometric input apparatus would have a 
hardware component comprising; a) at least one computing module for 
data processing; b) erasable and non-erasable memory modules for storage 
of data and software; c) a biometric scanner device for input of biometric 
data; dj a data entry device for entering data; e) a digital communications 
port; f) a device for prevention of electronic eavesdropping. 

in order to protect the integrity and comldentiaiity of electronic 
data sent between the biometric input apparatus, the tenninai, and the 
computer network, it is preferred that the data be encrypted and sealed. 

The host computer network is also connected to and is able to 
communicate with other independent computer systems, databases, 
facsimile machines, and other computer networks through c 



The method of the present invention includes voluntarily 
identifying an individual without the use of any tokens by means of 
examination of at least one biometrics sample provided by that the 
individual and a personal identification code also provided by that 
individual. During a registration step, the mdividuai is to register with the 
system an authenticated biometric sample, a personal identification code 
and a private code. Thereafter, during a bid step the biometrics sample and 
personal identification code of the individual is gathered and compared to 
the ones registered during the registration step. A match of the personal 
identification codes and biometrics sample will result in the positive 
identification of the individual. In order to authenticate to the identified 
individual that the real computer system was accessed, the individual's 
private code, which was collected at the registration step, is returned to 
the individual. 

It is preferred that the method of the invention include a method 
for examining the biometrics samples during registration and comparing 
such biometrics with a collection of biometrics samples from individuals 
who have been designated as having previously attempted to perpetrate or 
who have actually perpetrated fraud upon the system. 
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In a preferred embodiment, the invention includes a method for 
nonfyung authorities of the presence of exigent circumstances or that the 
authorized user is under duress. 

It is also preferred that a method of encryption and sealing of 
data be used to protect the data, including the digitized biometrics sample 
from bemg revealed accidentally or unveiled from crinunai elements during 
transmission. b 

It is also preferred that the method include steps for the 
wfatiu* to choose various financial accounts, and choose various modes 
or electronic transmissions. 

It is also preferred that the method include a method for 
archivmg of data and electronic transmissions, and retrieval of the archived 
data using a tracking code. 

It is furthermore preferred that any document, such as a 
facstmde or an electronic mail message be uniquely cheefcsummed using 
algonthm for future identification of the document. 

Yet another method of the invention is to be able to rapidly 
idemtfy an individual from an examinauon of his biometrics sample and 
personal toificarion code by storing several dissimxlar mometrics samples 
from different individual, in an electronic basket that is identified by one 
personal identification code. 

In one embodiment of the invention, the computer system can 
allow individuals to select their own personal identulcation code (or "PIC) 
from a group of PICs selected by the remote data processing center This is 
performed in a method whereby once the mdividual's biometric is gathered, 
the data processing center selects several PICs at random which mav be 
conduce to being memonzed. The data processing center then conducts a 
comparison of the biometric gathered with those already in those PIC 
baskets or groups. In the event the new registrant's biometnc is to sunilar 
to any previously registered biometric which has been allotted to any one 
of those randomly selected PIC groups, then that PIC is rejected bv the 
database for use by the new individual and an alternative PIC is selected for 
anotner such biometric comparison. Once the data processing center has 
generated several PIC options without a confusingly similar biometric 
those PICs are presented to the new registrant from which the individual 
may select one PIC . 
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In one embo diment of the invention, there is a method for 
rapid search of at least one first previously stored biometric sample 
from a first individual, using a personal identification code-basket that 
is capable of containing at least one aigorithmicaliy unique second 
biometric sample that is from at least one second mdrviduai, and which 
is identified by said personal identification code-basket, comprising, 
firstly, a storage step further comprising: a) the selection of a private 
code by a first individual; b) the selection of a p ersonal identification 
code by said first individual; c) the entering a biometric sample from 
said first individual; d) locating the personal identification code-basket 
identified by the personal identification code selected by said first 
individual; e) comparison of the biometric sample taken fr om said first 
individual with any previously stored biometric samples in said selected 
personal identification code-basket to make sure that the biometric 
sample entered by said first individual is aigorithmicaliy unique from the 
previously stored at least one biometric sample provided by at least one 
second individual, and; f) storage of the entered biometric sample from 
said first mdividuai in the selected personal identification code-basket if 
said sample is aigorithmicaliy unique from the at least one previously 
stored biometric sample from said at least one second individual There 
is also a bid step further comprising; a) entering said selected personal 
identification code by said first mdividuai, and; b) entering a biometric 
sample by said first individual. There is also a comparison step 
comprising: a) finding the personal identification code-basket that is 
identified by said personal identification code entered by said first 
individual, and; b) comparison of the entered biometric sample from 
said first individual with said at least one stored biometric sample from 
said at least one second individual in said entered personal identification 
code-basket for producing either a successful or faHed identification 
result. There could also be: a) an execution step wherein a command is 
processed and executed to produce a determination; b) an output step 
wherein said identification result or said determination is externalized 
and displayed, and; c) a presentation step wherein on successful 
identification of said first individual, said private code is presented ta 
said first individual. 
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Accordmg to one embodiment of the invention, the host system 
» posmoned in series between the individual betng identified and other 

It wdi be appreciated that in this embodiment, the user tenders an access 
request chrectly to the host computer system of the invention, which is 
operaHo^ yime ^ 

such as VISANET. The computer system would therefore maintain 
authenticated biometrics data samples for all authorized users of each 
secured computer system that it services. These data would be 
cross-referenced by each authorized user. Thus, after identity verification 
a completed, the security system provides to the user a feting of systems 
that he a authorized to access, and prompts the user to select the destred 
network. Thereafter, the requested execution step and mformation 
regarding the transaction is forwarded to the selected independent 
computer network similar to the type of communications sent today 
between merchants and credit card companies. 

In a second embodiment the host system may also carry out the 
Wons of the other independent computer systems such as debiting or 
credmng a financial account. In this system, the computer system of the 
mvention carries out the functions requested by the individual without use 
of external, independent computer networks. 

According to a further embodiment of the kventioa a means is 
provided for aierting predesigned authorities during an access attempt 
dunng which the user has been coerced by a third party to request access 
to the host computer system. In such an embodiment, an authorized user 
would have a number of codes, most of which would be recognized bv the 
computer system as the standard access codes, and others which would be 
recogmzed as emergency codes. The comparison means of the computer 
system of the invention would be configured to accept and recoanize at 
least one code per authorized user, and to activate the emergent alert 
means whenever the code entered by the user matched an emergencv code 
At the same tune, the determination of an authorized identity for the user 
woula result in the user being afforded access to the requested secured 
computer system perhaps on an access level that has been predetermined to 
be restricted or perhaps resulting m the dispiav of misleading data <i e 
"false screens"), thereby preventing the coercing third party from knowmg 
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that an emergency notification had been entered by the user. The 
emergency code would be entered as a pan of or simultaneously with the 
user's personal identification code or by selecting an emergency account 
index during the access of the computer system. In either case, the 
well-being of the user requesting access might be jeopardized if the 
coercing party discovered that the user was attempting to notify 
authorities. Thus, it is critical that the access procedure continue 
uninterruptedly and that access be granted to an authorized user so that the 
coercing party believes that everything is proceeding normally. Although 
these features can be incorporated into the invention's host computer 
network, it is aiso possible that an independent computer network can also 
carry out the same or modified versions of the above-mentioned features. 

The present invention is clearly advantageous over the prior an 
in a number of ways. First, it is extremely easy and efficient for the user, 
particularly where the user is accessing financial accounts, because it 
eliminates the need to carry and present any tokens in order to access one's 
accounts. The present invention eliminates ail the inconveniences 
associated with carrying, safeguarding and locating any desired tokens. 
Further, because tokens are often specific to a particular computer system 
that further requires remembering a secret code assigned to the particular 
token, this invention eliminates all such tokens and thereby significantly 
reduces the amount of memorization and diligence increasingly required of 
consumers by providing access to aii assets using only one personal 
identification code. Thus, in a single, tokenless transaction, the consumer 
can efficiently and securely conduct virtually any commercial exchange or 
electronic message, from withdrawing cash from a bank account, to 
authorization his agreement to the terms of a contract, to making a 
purchase directly from television, to paying local property taxes. The 
consumer is now uniquely empowered, by means of this invention, 10 
conveniently conduct his personal and/or professional electronic 
transmissions and transactions at any time without dependence upon tokens 
which may be stolen, lost or damaged. 

The invention is clearly advantageous from a convenience 
standpoint to retailers and financial institutions by making purchases and 
other financial transactions less cumbersome and more spontaneous. The 
paper work of financial transactions is significantly reduced as compared to 
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current systems, such as credit card purchase wherein separate receipts are 
generated for use by the credit card company, the merchant and the 
consumer. Such electronic tractions also save merchants and banks 
considerable time and expense by greatly reducing operational costs 
Because the system of the invention is designed to provide a consumer with 
simultaneous direct access to all of his financial accounts, the need for 
transactor* mvolvmg money, checks, commercial paper and the like will 
be greatly reduced, thereby reducmg the cost of equipment and staff 
required to collect and account for such transactions. Further the 
substantial manufacturing and distributing costs of issuing and reissuing 
credit cards, ATM cards, calling cards and the like will be eliminated 
thereby providing further economic savings to merchants, banks, and 
ultimately to consumers. In fact, the system of the invention will likely 
spur economic growth since all of a consumer's electronic financial 
resources will be available at the mere input of his fingerprint or other 
biometrics, 

The invention is markedly advantageous and superior to 
exmmg systems in being highly fraud resistant. As discussed above, 
present computer systems are inherently unreliable because thev base 
d etermination of a user's iden tity on the physical presentation of a unique 
manufactured object along with, in some cases, information that the user 
knows. Unfortunately, both the token and information can be transferred 
to another, through loss, theft or by voluntary action of the authorized ' 
user. Thus, unless the loss or unintended transfer of these items is realized 
and reported by the authorized user, anyone possessing such items will be 
recogmzed by existing security systems as the authorized user to whom 
that token and information is assigned. 

By contrast, the present invention virtually eliminates the risk of 
granting access to non-authorized users by determining user identity from 
an analyse of one or more of a user's umo.ee, biometrics characteristics 
Even m the very rare circumstance of coercion, where an authorized 
uAvidul is coerced by a coercmg party to access his accounts, the svstem 
annates an emergency account index, whereby the authorized user'can 
alert authorities of the transgression without the knowledge of the coercing 
parry. s 
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The invention further enhances fraud resistance by maintaining 
authenticating data and carrying out the identity verification operations at a 
point in the system that is operationally isolated from the user requesting 
access, thereby preventing the user from acquiring copies of the 
authenticating data or from tampering with the verification process. Such a 
system is clearly superior to existing token-based systems wherein 
authenticating information, such as personal codes, is stored on and can be 
recovered from the token, and wherein the actual identity determination is 
potentially in operational contact with the user during the access process. 

It is an object of the invention therefore to provide a computer 
access identification system that eliminates the need for a user to possess 
and present a physical object, such as a token, in order to initiate a system 
access request. 

It is another object of the invention to provide a computer 
access identification system that is capable of verifying a user's identity, as 
opposed to verifying possession of proprietary objects and information. 

It is yet another object of the invention to verify user identity 
based upon one or more unique characteristics physically personal to the 
user. 

Yet another object of the invention is to provide a system of 
secured access that is practical, convenient, and easy use. 

Still another object of the invention is to provide a system of 
secured access to a computer system that is highly resistant to fraudulent 
access attempts by non-authorized users. 

Yet another object of the invention is to provide a computer 
access identification system that enables a user to notify authorities that a 
particular access request is being coerced by a third party without giving 
notice to said third patty of the notification. 

There is also a need for a computer access identification system 
that automatically restricts a user's transactional capabilities on the 
computer system according a desired configuration provided by the user. 

These and other advantages of the invention will become more 
fully apparent when the following detailed description of the invention is 
read in conjunction with the accompanying drawings. 
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Brief Description *f » Be Drawing * 

FIG. 1 is a diagram of the system of the present invention; 

FIG, 2 is a diagram of the Data Processing Center (DPC) and 
its internal data bases and execution modules; 

FIG. 3 is a diagram of the retail point of saie terminal, the 
biometrics input apparatus and its components, and the interconnections 
between them; 

FIG. 4 is a flow chart of the operation of the biometrics input 
apparatus and the terminal for generating a request packet; 

FIG. S is a representational diagram of the request packet and 
the mandatory and optional data it contains; 

FIG. 6 is a representational diagram of the response packet and 
the mandatory and optional data it contains; 

FIG. 7 is a flow chart depicting the data encryption and sealing 
process at the biometrics input device; 

FIG. 8 is a low chart depicting the data decryption and counter 
party identification process at the DPC; 

FIG. 9 is a Sow chart depicting the data encryption and sealing 
process at the DPC; 

FIG. 10 is a flow chart representing the registration of an 
individual during the registration process; 

FIG. U is a flow chart representing the process of 
identification of the individual and returning a private code to the 
individual; 

FIG. 12 is a flow chart of the skeleton of the processes that 
occur at the DPC and an execution step; 

FIG. 13 is a fl ow chart of the emergency request and response 
process at the DPC; 

FIG. 14 is a flow chart of the overall operation of retail 
transaction authorization execution at the DPC 

FIG. IS is a flow chart of the overall operation of remote 
transaction authorization execution step at the DPC; 

FIG. 16 is a flow chart of the overall operation of ATM 
account access execution at the DPC; 
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FIG. 17 is a flow chart of the overall operation of issuer batch 
modification execution at the DPC; 

FIG. 18 is a fiow chart of the overall operation of secure fax 
submit and electronic document submit execution at the DPC; 

FIG. 19 is a flow chart of the overall operation of secure fax 
data and electronic document data execution at the DPC; 

FIG. 20A is a representational diagram of the electronic 
signature request packet; 

FIG. 20B is a representational diagram of the electronic 
signature response packet; 

FIG. 20C is a representational diagram of the electronic 
signature verification request packet; 

FIG. 2GB is a representational diagram of the electronic 
signature verification request packet; 

FIG. 21 is a fiow chart of the overall operation of electronic 
signature execution at the DPC; and 

FIG. 22 is a fiow chart of the overall operation of electronic 
signature verification execution at the DPC. 

Detailed Descri ption of the Drawings 

As noted, the main objective of this invention is to provide a 
tokenless, secure, reliable, safe, and consistent, apparatus and method, for 
identifying individuals for the purpose of performing financial transactions 
and non-financial transmissions, which can accommodate large numbers of 
users. It is the essence of this invention that consumers have the ability to 
conduct these transactions without the use of any tokens, credit cards, 
badges or identification cards including drivers licenses, 'in order to be 
functional it is important that the system operate at speeds required for 
completing financial transactions such as credit card purchases and ATM 
services, from multiple banks and credit accounts. The system must be 
secure, such that individuals records and their biometrics information 
remain confidential and safe, both within the computer system that 
identifies the individual and authorizes transactions, or during transfer of 
data between the computer system and remote sites with which the 
computer system communicates. Furthermore, the system must be reliable 
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mjto errors „ tdentification and authorization must no, hamper or nuke 
use of the system cumbersome. Since only the use of biometiica are 

««»y measures «o other reduce access, even ,o the authorised us« or 
^a„uao nMsmeTOrWTOItiswr ^ tedttetjM ^- 

mus be able.ohand.ealargenu.nberof,^ and accomrnodat, storage 
-d n* of large amounts of data, such as bio^-aaeristic 

^. ^ "° W '° tte ^ "* ov«aH configuration of the 
mventton and ,t> components are shown i, n G . 1 . Essentially a Data 
Process Center (DPC) I is connected to various terminals 2 through 
f ""-»'"*■ — » which can be one of several types 

ZT ^^^^^^-^eeJtion 
- -J.-ta.mi toap^edembodhnentcfUteinvenuon, 

Machtne , ,s response for prevention of electronic bmtsion of the 
system whue the Macime , „ ^ 

^databases. The Gateway Machine is also responsible for decryption'J 

module 7, MDM module 8. and the SNM module 9. The PGL module 1. 
-d^MLmo.uieUareusedtolocatemepnoperpersoT " 
.oennncation code and biometncs sampie basket. FIG. 3 deptas an 
example of a terminal and the biometrics input device 12. which has a 
bnne. scanner 13. data entry means such as a key pad or hn pad 14 
andadtsplaypanel.5. The biomemcs scanner can be any one of finger ' 
pnnt scanner, voice recognition, pain, pnm scanner, retinal scanner or the 
uke, although the fingerprint scanner will be used as an example The 
btonwrrcs utpu, device is further equipped with computus mod uies 16 
devtcedttvers, and erasable and nonerasable memorv modules The ' 

a senal port 17 The termmal 1 communicates through a convemional ' 
mo em I. w ,h the DPC , through, request packets It and response 
packets 20 using one of the interconneaing means i„HG. 1 such as cable 
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network, cellular telephone networks, telephone networks, Internet ATM 

packet 1 9 and its method of generation by the biometrics input device 
software, FIG. 5 and FIG. « show a representational diagram of the 
revest packet and response packet with optional and mandatory data 
segments. Furthermore, it is shown which parts of the packets are 
encrypted and which ones are sealed. FIG, ? is a block diagram of the 
overall process for data encryption and sealing showing the use of DUKFT 
key data 20 for encryption of data before appending additional data beibre 
seakng the request packet with a Message Authentication Code Key 
(MAC) 21. FIG. 8 and FIG. 9 show the decryption and encryption 
process at the DPC. FIG. 12 through 19 and 21 through 22 are block 
diagrams of selected examples of execution steps carried on at the DPC. 

Description of the drawings, diagrams, flow charts and the 
description of the invention, including hardware components, software 
components, execution modules, data bases, connection means, the data 
transferred between them, and the method of the invention is described in 
detail as follows. 

IX Btometric Input Apparatus (BIA) 
14.X. Introduction 

The BIA is a combination of hardware and software whose job 
a to gather, encode, and encrypt biomeiric input for use in individual 
^entmcadon. All actions of the BIA are directed by an outside controlling 
enwy called a terminal, which issues commands and receives results over 
the BIAs serial line. 

BIA hardware comes in four basic versions: standard wireless 
integrated phone/cable television (or "CATV's/fax, and ATM. Each BIA* 
hardware variant addresses a particular need in the marketplace, and 
because of the differences in construction, each variant has a different ievel 
of security. 

BIA software comes in seven basic versions: personal computer 
(or "PC"), retail, ATM, registration, internal, issuer, and integrated remote 
Eacn software load provides a different, use-specific command set. For 
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instance, the registration software load does not accept requests to form 
retail transaction messages. Likewise, the retail software command set 
cannot send individual registration messages. To provide another layer of 
secure the DPC knows what software package is loaded into eachBIA; 
any attempts fay an BIA to send a message that it is normally not able to ' 
send is rejected, and treated as a major security violation. 

The ability of the invention to detect and combat 
merchant-based fraud reHes on the fact that the BLVs external interface is 
smaty limited, that the common of tkeBL^zkmtzm4y m^t 
to tamper with the contents, that each BIA has its unique encryption codes 
that are known only to the DPC, and that each BIA is only allowed to 
perform operations limited to its designated function. Each (metric input 
means has a hardware identification code previously registered with the 
Which aate * «** bioinetric input means uniquely identifiable to the 
DPC m each subsequent transmission from that biometric input device. 

The BIA is constructed with the assumption that the controlling 
terminal is a source for fed and deception. Terminals range from 
software applications running on personal computers to dedicated 
hardware/software systems developed for a particular use such as a retail 
pomt of sale. Regardless of the particular model, no BIA reveals 
unencrypted biometric information. BIA models without dispiav means 
{such as LCD. LED, or quartz screens) must reveal selected information 
isuch as mdtvidual private codes) to the tennaai for display, and as a result 
those particular termmal-BlA combinations are considered to be less 
secure. 

Depending on the task at hand, BIA models are either partially 
or My integrated with the terminal. Partially integrated devices are 
pnysjcaily separate from the terminal and they include wireless and 
standard retail point of sale BIA.. Fully integrated devices are contained 
withm the physical enclosure of the terminal itself, for instance, an ATM, 
or a telephone. 

No BIA ever discloses any secret encryption codes to any 
external source. 
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1.1.2. B14 Models 



Parties BIA hardware models have different conizations 
They are introduced in brief here: 



MIA 



Standard model has computing module (i.e., multichip 
modules), biometric scanner (i.e., single fingerprint scanner), display means 
(i-c, LCD screen), communications port <i,e., serial port) , data entry 
means (i.e, a manual data entry key board or PIC pad) encased in 
tamper-resistant case, and electronic detection means (i.e., RF shielding). 

BlAAVireiess 

Standard model, but serial line replaced wufa spread-spectrum 
wireless communications module using external antenna. Used in 
restaurant point of sale. 



Has heavy-duty scanner and serial port, along with a muiticMp 
module. The fact that the LCD is part of the terminal and not the BIA 
means lower security because it must reveal the private code to the 
terminal. Used in ATMs. 

BIA/Catv 

Has light-duty scanner, otherwise like ATM. Used in 
telephones, CATV remotes, and fax machines. Weakest security both 
because the LCD and PIC pad are part of the terminal not the BIA, and 
because of the low-con nature of the market. 

1.1,3. BIA Command Set Messages 

Each BIA software .command set provides a different set of 
operations. They are introduced briefly here: 

BJA/ATM 

Account Access 
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BIA/Catv 

Remote Transaction Authorization 

BIA/Fax 

Secure Fax Submit 

Secure Fax Data 

Secure Fax Tracking 

Secure Fax Retrieve 

Secure Fax Reject 

Secure Fax Archive 

Secure Fax Contract Accept 

Secure Fax Contract Reject 

Electronic Document Archive Retrieve 

BIA/Interaal 

Individual Identification 

BIA/Issuer 

Issuer Batch 

BIA7PC 

Electronic Document Submit 
Electronic Document Data 
Electronic Document Tracking 
Electronic Document Retrieve 
Electronic Document Reject 
Electronic Document Archive 
Electronic Document Archive Retrieve 
Electronic Signature Submission 
Electronic Signature Check 
Remote Transaction Authorization 
Network Credential 
Secured Connection 
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BIA/Registratioo 

Individual identification 
Biometric Registration 

Transaction Authorization 
1.L4. MIA Hardware: Standard Model 



The Standard BIA hardware is a muitichip module combined 
with a singie-print scanner, an LCD screen, a serial port, and a PIC pad 
encased in a ted tamper^stant case that malces attempts to penetme 
obvious while also providing RF shielding for the contents. 

The Mowing components are amaigamated into a muitichip 
module, called the BIA Muitichip Module (a process for encapsulating 
several processors in one physical shell, well known in the industry) 
constructed to protect the communications pathways between the devices 
from easy wiretapping. 

* Serial processor 

* HC pad processor 

* LCD screen processor 

* CCD scanner A/D processor 

High-speed DSP processor containing both flash and mask 
ROM 

* General purpose microprocessor 

* Standard RAM 

* EEPROM 



The following software packages and data are stored in mask 
ROM. Mask ROM is cheaper than other types of read only memory, hut 
» easily reverse engineered, and is not electronically erasable. .As such w, 
only place the noncritical commonly available code here. (Mask ROM is 
well known in the industry). 
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* MAC calculation library 

* DUKPT Key Management library 

* DES (with CBC) Encryption library 

* Base-64 (S-bit to printable ASCII) convener library 

* Public Key Encryption library 

* Embedded Operating System 

* Serial line device driver 

* LCD device driver 

* PIC pad device driver 

* Scanner device driver 

* Unique hardware identification code 

* Multi-Language profiles 



The following standard data and software packages are stored 
to flash ROM. Flash ROM is more expensive, but it is much more difficult 
to reverse engineer, and most importantly, it is electronically erasable. All 
of the more critical information is stored here. Flash ROM Is used in an 
attempt to increase the difficulty of duplicating an B1A. (Flash ROM is 
well known in the industry). 



* Unique DUKPT Future Key Table 

• Unique 1 12-bit MAC Key 

• DSP biometric quality determination algorithm 

* DSP biometric encoding algorithm 

♦ Random number generator algorithm 

* Command function table 



The message sequence number, incremented each time a 
message is sent from the BIA, is stored in the EEPROM. EEPJtOM can be 
erased many tiroes, but is also nonvolatile — Its contents remain valid 
across power interruptions. (EEPROM is well known in the industry). 

The following data is stored in RAM. RAM is temporary in 
nature, and is lost whenever power is lost, 



Encoded Biometric Register 
PIC Register 
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» Account Index Code Register 

* Title Index Code Register 

* Amount Register 

* Document Name Register 

* PlC-Block Key 

* Message Key 
» Response Key 

* Shared Session Key 

* Private Session Key 

* S General Registers 

* stack and heap space 



Each nuiitichip module contains a "write-once" memory location that is 
irreversibly set foUowing the initialization of the flash ROM. Whenever a 
attempt is made to download software to the flash ROM, this memory 
location is checked; if it is already been set, then the BIA refuses to load. 
This way, critical software and data keys may only be downloaded once 
into fee device, at the time of manufacture. 



All registers and keys are explicitly zeroed when a transaction 
is canceled. Once a transaction is completed, registers are cleared as well. 
Once a "form message" command is executed, biometnc, PIC, and accounr 
index code registers are also cleared, along with any encryption keys that 
arent required for subsequent use. 

It is important that the software not keep copies of registers or 
keys in stack variables {known in the industry). 

The foUowing associated hardware components comprise the 
standard BIA hardware module. 



• BIA Multichip module 

» CCD single-print scanner 

• capacitance detector plate (known in the industry) 

• lighted PIC keypad 

» 2-line 40-coiumn LCD screen 

• RF shieidmg 

• tamper-resistant case 
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* serial connection (up to 57.6kb) 

breech detection hardware (known in the industry) 

• optional thenmte charge attached to MuiticWp module (known 
in the industry) 

Ail temporary storage and internal hardware and software used 
o calculate these values are secured, which means they resist any attempts 
odetennmetheircurrent^ ^ 
tore is essential for the security of the invention, Just as it Critical that 
the wetappnig" 0 f an BIA and specifically the gathenna of a 
Brometric-PIC Block for fraudulent means is made as diicult as possible 
Themuiticfaip module and the components are, where practical 
physcaily connected to each other without exposed wiring beine present ' 
The enclosure protecting the electronic comnonents of the BIA 
IS welded shut during manufacture; it cannot be opened under anv 
crrcumstances without significant damage to the case. Upon detecring any 
opening <or damage) of the enclosure, the BIA performs an emergency 
e ectromc zero of any and all keys residing m flash ROM followed by all of 
the software libraries. Specific breech detection methods are kept 
confidential and proprietary. 

in addition to protecnng the contents, the case also shields the 
internal operations from RF signal detectors. 

Supersede versions of the BIA exist wherebv breech detection 
methods are connected to a mechanism that physically destroys the 
mumcbp module as well as the detection methods themselves. 

1.L5. BIA Hardware: Wireless Model 

The Wireless version of BIA hardware is identical to the 
Standard model in construction, except that it exports a spread-spectrum 
wu-eless communications module using an external antenna instead of an 
external serial port. 

This version is designed to be used in restaurants, where 
transactions are authorized at the customer's convenience. 
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fa the foHowiag descriptions, items which are added to the 
standard set are signified by the + character, wtie items that are removed 
from the standard set are signified by the - character. 



Maltiehip Module: 

- Document Name Register 
-Shared Session Key 
-Private Session Key 

- Message Key 



Components: 

- Serial port 

+ External antenna 

+ Spread-spectrum wireless serial module (known in the 
industry) 



1.1.6, BIA Hardware: ATM Model 



The AIM version of BIA hardware is a muMcMp module 
combined with a heavy-duty single-print scanner and a serial port. The 
components are encased in a tamper-resistant case that makes attempts to 
penetrate obvious while also providing RF shielding for the contents. 

This version is designed to be retrofitted into ATM locations. 
As such, the scanner pad is a heavy-duty sensor pad, and the entire 
construction makes use of the existing screens and keypads present in the 
ATM itself. 

In the following descriptions, items which are added to the 
standard set are signified by the + character, while items that are removed 
from the standard set are signified by the - character. 



Multichtp Module: 

- Amount Register 

- Document Name Register 

- Shared Session Key 

- Private Session Key 
-Message Key 
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Components: 

~ lighted PIC keypad 

- 2-line 40-column LCD screen 

Note that since the ATM has no LCD screen or PIC keypad, it 
really has no need of those device drivers in the mask ROM. 

1X7. BIA Hardware: Phone/CATV Model 

The Phone/CATV version of BIA hardware is a muitichip 
module combined with a single-prim scanner and a serial port. The 
module » physically attached to the scanner, and the whole is encased in 
plastic in order to make tampering more difficult. Some amount of RF 
shielding is provided for the components. 

This version is designed to be integrated with telephones, 
television remote controls, and fax machines. As a result, it makes use of 
the existing keypads and LCD or television scr eens to enter or display 
values. It also uses the communication facilities of the host terminal For 
example, the fax machine uses the built-in fax modem and the television 
remote uses the CATV cable network. 

This hardware model is (in comparison with other models) 
relatively insecure, as it is intended that these devices cost as Mttle as 
possible, be lightweight, and integrate easily with existing low-cost 
devices. 

Of course, higher-security versions with more complete 
enclosures are possible and encouraged. 

In the following descriptions, items which are added to the 
standard set are signified by the -h character, while items that are removed 
from the standard set are signified by the - character. 

Muitichip Module! 

~ Document Name Register 

- Shared Session Key 

- Private Session Key 

- Message Key 
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Components: 

- lighted PIC keypad 

- 2~line 40-coiumn LCD screen 

1.2. BXA Software 

1.2.1. BJA Software Command Interface: 

The externa* interface to the BIA is much like a standard 
modem; commands are sent to it from a controlling tenninai using the 
external serial line. When a command completes, a response code is sent 
from the BIA to the terminal. 

Each BIA software load supports a different set of operations. 
For instance, a retail load supports only transaction authorizations, while a 
registration load supports individual identification and biometric 
registration. 

All BIA data fields are in printable ASCII with fields separated 
by field separator (or Ts") control character, and records separated by 
newlines. Encrypted fields are binary converted to 64-bit ASCII using the 
base-64 conversion library (all known in the industry). 

Some commands are not available in some configurations. For 
instance, the ATM BIA cannot 'Get PIC", since there is no attached PIC 
pad. Instead, the ATM BIA supports a "Set PIC" command. 

Response Cndgs * 

Out of time: 

The time allotted for the command has expired. A message to 
that effect will be displayed on the LCD screen, if available. When time 
expires for a given command, the BIA acts as if the cancel button was 
pushed. 

Canceled: 

The "cancel" button has been pushed, and the entire operation 
has been canceled. This has the side effect of clearing all information 
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which was gathered. A message to that effect will be displayed on the 
LCD screen, if available. 

Ok: 

The command was successfiii. 

Other: 

f^^^^ytovespecificotherrespo^codeswhich 
are vahd only for it. These response codes m generally have tes* 

Message; 

This indicates that the command is ongoing, but that the BIA wants to 
send a message to the terminal with an interim result message. The result 

as well as status messages. F ^ 

Commands: 

la the argument list of the commands below, the o characters 
-mo* MiU arguments, Q characters sutround optional arguments 
and the character indicates that a given argument maybe comprised of 
one of the choices presented. 

Set Language <language-natBe> 

This command selects from one of a number of different 
languages encoded within the BIA for prompting for user input. 

Gtt Biometric <tiiae> fpriraaryjsecondaryl 

This command requests the BIA to activate its scanner to set 
bouemc input from the individual storing it into the Encoded BWric 
Register. 

First, the message "Please place finger on lighted panel" is 
delayed on the LCD panel and returned to the tertninal The scanner pad 
(s niummated, prompting the individual to enter his biometric 
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A <tinie> value of zero means that there is no limit to the time 
tor biometric scan input. 

When in scanning mode, a fingerprint scan is taken and given a 
prehmmary analysis by the print quality algorithm. If the scan is not good 
enough, the BIA continues to take new scans untii <time> seconds pass 
As time passes and snapshots of the print are taken and analyzed, messages 
are posted to the LCD screen and sent to the terminal based on the 
problems detected by the print quality software. If no print of appropriate 
quality is forthcoming, the BIA returns an error code of time expired 
displaying a message to that effect on the LCD. 

Once the prim quality algorithm affirms the Quality of the print 
scan, the print's minutiae are then extracted by the print encoding 
algonthm. Only , subset of the minutiae are selected at random, with care 
taken to retain enough sufficient for identification. These minutiae are then 
ordered randomly, and are placed in the Encoded Biometric Register. 
Then the BIA responds with the success result code. 

If the [primaryjsccondary] is specified (only available in the 
oiometric registration command set) then the entire minutiae set is selected 
not just the smaller subset. Likewise, prhnary/secondary biometric 
selecnon ends up placing the encoded biometric into the appropriate 
register. 

Whether or not the operation succeeds, as soon as scanning has 
tennumed, the light indicating that scanning is m progress is turned off. 

It is very important that the same biometric input yields 
different encodings, so as to complicate the task of anyone attempting to 
mscover the encryption codes of a captured BIA. This is accomplished by 
the selects of a random subset and random ordering of the encoded 
biometric. 

Get FIC <ii»e> 

This command requests the BIA to fill the PIC Register by 
reading from the keypad. 

First, the message "Please enter your PIC, then press <enter> !1 
55 fepiayed m the LCD «ay and sent to the terminal the appropriate 
keypad lights are turned on, and then keypad scanning begins 
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Scanning terminates when either <time> number of seconds 
runs out, or when the individual hits the "eater" key. 

Note that the individual digits of the PIC are not displayed on 
the LCD panel, but for each digit the individual types, a star appears to 
give the individual feedback. When the "correction" key is pressed, the last 
digit entered is erased, allowing the individual to fix input mistakes. 

When PIC input terminates, the keypad lights turns off. 

If successful, the command returns OK. 

Get Account index Code <time> 

First, the message "Now enter your account index code, then 
press <enter>" is displayed on the LCD and sent to the terminal. This 
prompts the individual to enter his account index code. When each key is 
pressed, that value appears on the LCD panel. The correction button can 
be pressed to erase one of the values. When the "enter" button is pressed, 
the Account index code register is set. 

During input, the appropriate keypad keys are lit, and when 
input is concluded, the keypad lights are turned off 

If successful, the command returns OK. 

Get Title Index Code <time> 

First, the message "Please enter your title index code, then press 
<enter>" is displayed on the LCD and sent to the terminal. This prompts 
the individual to enter his title index code. When each key is pressed, that 
value appears on the LCD panel The correction button can he pressed to 
erase one of the values. When the "enter" burton is pressed, the Title Index 
Code register is set. 

During input, the appropriate keypad keys are lit, and when 
input is concluded, the keypad lights are turned off. 

If successful, the command returns OK. 

Validate Amount <amount> <time> 

The Validate Amount command sends the message "Amount <amount> 
OK?" to the terminal and displays it on the LCD screen. If the individual 
confirms the amount by hitting the "yes" (or enter) button, the Amount 
Register is set to <amount>. The <amount> value must be a valid number, 



33 



with no control characters or spaces, etc. During prompting, the yes, no, 
and cancei buttons are lit. Once prompting is complete, ail the lights are 
turned off. 

If the individual enters "no", then the transaction is canceled. 

£ater Amount <time> 

The Enter Amount command sends the message "Enter 
amount" to the terminal, and also displays it on the LCD screen as well. 
The individual must then enter the dollar amount himself. Each character 
entered is displayed on the LCD screen. All appropriate buttons are lit. If 
the enter button is hit, the Amount Register is set to be the value entered 
on the keyboard. Once entry is complete, all the lights are turned off. 

Validate Document <natne> <»me> 

The Validate Document command sends the message 
"Document <name> OK? N to the terminal, and displays it on the LCD 
screen as well. If the individual confirms the document by hitting the "yes" 
(or enter) button, the Document Name Register is set to <name>. The 
<name> must be printable ASCII with no control characters, and no 
leading or trailing spaces. During prompting, the yes, no, and cancel 
buttons are lit. Once prompting is complete, ail the lights are turned off. 

If the individual enters "no", the transaction is canceled. 

Assign Register <register> <teit> 

The assign register command sets the designated General 
<registcr> to have the value <text>. This is used to set information such as 
the merchant code, the product information, and so on. 

Get Message Key 

The Get Message Key command causes the BIA to generate a 
56~feit random key to be used by the controlling hardware to encrypt any 
message body that the controlling device wishes to add to the message. 
That generated key is returned by the BIA in hexadecimal format (known 
in the industry). The message key are then added to the biometric-MC 
block. 
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Form Message <type->de Q tincatioaitnins a cti 0 ii{aceouat access 

The form message command instructs the BIA to output a 
message cootamrag all the Marmation It has gathered. It also checks to 
make sure that all the registers appropriate to that specific message <type> 
have been set. If all required registers are not set, the BIA returns with an 
error. The specific command set software will determine which messages 
can be formed by that BIA model; m others will be rejected. 

Each message includes a transmission code consisting of the 
BIA's unique hardware identification code and an incrementing sequence 
number. The transmission code allows the DPC to identify the sending BIA 
and to detect resubmission attacks. 

The BIA uses the DUKPT key management system to select the 
biometric-PIC block encryption 56-bit DES key from the Future Key 
Table. This key is then used to encrypt the Biometric-PIC Block using 
cipher block chaining (CBC). In addition, a response DES key is also 
generated randomly, and is used by the DPC to encrypt the portions of the 
response that need to be encrypted. 

Note; splitting the response key from the biometric-PIC block 
key is very important, since each encryption key must be used only within 
the context of its own responsibilities. That way, if someone were to break 
the key encoding the private code, it would not result in the disclosure of 
the biometric-PIC. 

The Biometric-PIC block consists of the following fields; 
300-byte authorization biomctric 
4-12 digit PIC 
56-bit response key 
{optional 56-bit message key] 

Note that the message key is only present if the controlling 
terminal has requested a message key for this message. It is up to the 
controlling terminal to encrypt any message body attached to the 
transaction authorization request using the message key, 

Once all encryption is complete, the BIA outputs the body of 
the appropriate request message (such as a Transaction Authorization 
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Request message), terminated by and protected with the Message 
Authentication Code (MAC), 

The MAC field is calculated using the BIA's secret 1 12- bit 
DES MAC key, and covers ail message fields from first to last. The MAC 
assures the DPC that nothing in the message has changed effectively 
sealing the message, while still allowing the plaintext fields to be Inspected 
by the controlling terminal. 

When the Form Message command is done, the BIA sends the 
message Tm talking to DPC Central" to the terminal as well as displaying 
it on the LCD screen, indicating that work is proceeding on the request. 

The command returns OK in addition to retailing the entire 
formed message upon completion of the command. 

Show Response <encrypted response> <tiiae> 

The Show Response command instructs the BIA to use its 
current Response Key to decrypt the private code from the system. 

After decryption, a chime sounds, and the private code is 
displayed on the LCD screen for <time> seconds. At no time does this 
command transmit the decrypted private code to the controlling terminal. 

Validate Private <eocrypted vaiidation> <time> 

This command is used by a terminal during a secure network 
communications session to ask the individual to validate a message from an 
outside source. The message comes encrypted and in two parts: the 
challenge, and the response. 

Upon receipt of a Validate Private command, the BIA displays 
the text of the challenge message as in "OK <challenge>? " on the LCD 
screen, but does not send this to the terminal. When the individual 
validates the challenge, the response is encrypted by the BIA using the 
Private Session Key, and then returned to the terminal along with the OK 
response code. If the individual does not validate the challenge, then the 
BIA returns with a "failed" response code, along with the text "transaction 
canceled at your request," which is also displayed on the LCD screen. 

Note that the terminal is never allowed to see the plaintext of 
either the challenge or the response. 
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Reset 

The Reset command instructs the BIA to dear ail temporary 
registers, the LCD screen, aO temporary Key registers, and to turn off all 
keypad lights that may be on. 

5 

Set PIC <value> 

This command assigns the BIA's PIC Register to be <vaiue>. 

Note that allowing a non-secured device to provide the PIC is a 
10 potential security problem, because non-secured devices are much more 

vulnerable to wiretapping or replacement. 

Set Account index code <value> 

This command assigns the BIA's Account index code Register 
*S to be <value>. 

Note that allowing a non-secured device to provide the account 
index code is a potential security problem, because non-secured devices 
are much more vulnerable to wiretapping or replacement. 

20 Set Title Index Code <vaiue> 

This command assigns the BIA's Title index Code Register to 
be <value>. 

Note that allowing a non-secured device to provide the Title 
Index Code is a potential security problem, because non-secured devices 
25 are much more vulnerable to wiretapping or replacement. 

Set Amount <value> 

This command assigns the BIA's Amount Register to be 

<value> 

30 

Decrypt Response <encrypted response message> 

The Decrypt Response command instructs the BIA to use it's 
current Response Key to d ecrypt the encrypted p orti on of the response 
message. Once decrypted, the response is returned to the controlling 
35 device, presumably for display on the ATM terminal's LED screen. 
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Note that providing this decryption ability is a security problem, 
as once the plaintext leaves the BIA, the terrains] has the ability to do with 
it what it will . 

1-2.2. BIA Software: Support Libraries 

The BIA software is supported by several different software 
libraries. S ome of them are standard, generally available libraries, but some 
have special requirements in the context of the BIA. 

L2.2.L Random Number Generator 

Since the BIA is constantly selecting random DES keys for use 
k the message body and message response encryption, it is important that 
the keys selected be unpredictable keys. If the random number generator is 
based on time of day, or on some other externally-predictable mechanism, 
then the encryption keys will be much more easily guessed by an adversary 
that happens to know the algorithm. In order to assure the security- of the 
encryption techniques used in the BIA, it is assumed that both the random 
number generator algorithm as well as the encryption algorithms are both 
publicly known. 

A standard random number algorithm for generating DES keys 
is defined in ANSI X9. 17, appendix C (known in the industry). 

1-2.2.2. DSP Btometrk Encoding Algorithms 

The biomerric encoding algorithm is a proprietary algorithm for 
locating the minutiae that are formed by ridge endings and bi&rcations on 
human fingertips. A complete list of minutiae is stored in the DPC as a 
reference, while oniy a partial list is required by the algorithm when 
performing a comparison between an identification candidate and a 
registered individual. 

During both bioraetric registration as well as identification, the 
encoding algorithm ensures that enough minutiae are found before ending 
the faiometric input step. 
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1.2,2.3. Operating System and Device Brivers 

The BIA is a realtime computing environment, and as such 
nqmns a realtime embedded operating system to run it. The operating 
systen is responsible for taking interrupts from devices and scheduling 

Each device driver is responsible for the interface between the 
operating system and the specific hardware, such as the PIC pad device 
driver, or the CCD Scanner device driver. Hardware is the source for 
events such as TIC pad key pressed", or "CCD Scanner scan comdete" 
The device driver handles such interrupts, interprets the events, and then 
takes action on the events. 

1X2.4. DES Encryption Library 

There are any number of DES implementations publicly 
available. DES implementations provide a secret key-based encryption 
from plaintext to dphertext, and decryption from ciphertext to plaintext 
«smg 56-bit secret keys. 

L2.2.S, Public Key Encryption Library 

Public Key encryption support libraries are available from 
^biic Key Partners, holders of the RSA public key patent (known in the 
industry). Public Key cryptosystems are asymmetric encryption systems 
that allow communication to take place without requiring a costly 
exchange of secret keys. To use a public key encryption system, a public 
key 3 s used to encrypt a DES key, and then the DES key is used to encrypt 
a message. The BIA uses public key cryptosystems to provide for the 
secure exchange of secret keys. 

Unfortunaxeiy, public key systems are significantly less well 
tested than secret-key systems, and as such there is an overall lower level 
of confidence in such algorithms. As a result, the invention uses public kev 
cryptography for communications security and short-lived credential 
exchange, and not long-term storage of secrets. Both the end-user 
individual and the bank are identified by the DPC to create the network 
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credential. The network credential includes the end-user individual's 
identification as weE as the context of the connection (i.e., the TCP/IP 
source and destination pons). 

1.2,2.6. DUKPT Key xManagement Library 

The derived unique key per transaction key (DUKPT) 
management library is used to create future DES keys given an initial key 
and a message sequence number. Future keys are stored in a Future Key 
Table. Once used, a given key is cleared from the table. Mia! keys are 
only used to generate the initial future key table. Therefore the initial key 
is not stored by the BIA 

The use of DUKPT is designed to create a key management 
mechanism that provided a different DES key for each transaction, without 
leaving behind the trace of the initial key. The implications of this are that 
even successful capture and dissection of a given future key table does not 
reveai messages that were previously sent, a very important goal when the 
effective ufetime of the information transmitted is decades. DUKPT is fully 
specified in ANSI X9.24 (known in the industry). 

DUKPT was originally developed to support PIC encryption 
mechanisms for debit card transactions. In this environment, it was critical 
to protect all transactions. An assumption is made that a criminal records 
encrypted transactions for a six month period, and then captures and 
successfully extracts the encryption code from the PIC pad. The criminal 
could then manufacture one new counterfeit debit card for each message 
that had been transmitted over that six month period. Under DUKPT, 
however, the criminal's theft and dissection would not allow him to decrypt 
previous messages (although new messages would still be decryptable if the 
criminal were to replace the PIC pad subsequent to dissection). 

In the biometric-PIC situation, the criminal has an even harder 
time, as even if messages are decrypted, turning a digital biometric-PIC 
into a physical fingerprint is much harder than turning an account 
number-PIC into a plastic card, which is one of the significant benefits of 
the tokenless system. 

Still if a criminal can decrypt, he can encrypt, which might 
allow him to eiectronicaiiy submit a biometric-PIC to the system to 
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authorize a fraudulent transacttoo. While this is quite difficult, it is stSi best 
to restrict the options available to the criminal as much as possible, hence 
the use ofDUKPT. 

1.3, BIA Software Command Sets 

1.3.1. BIA Software: Retail Command Set 

The BXA/Retail software interface exports an interface that 
allow* specific retail point of sale terminals to internet with the system. 

The BIA/Retail interface Is designed to allow the terminal to 
perform the following operation: 

Transaction Authorization 

In order to implement those operations, the BIA/Retaii provides the 
following command set: 

Set Language <ianguage~name> 
Get Biometric <time> 
Get PIC <time> 

Assign Register <register> <value> 
Get Account index code <rirne> 
Validate Amount <arnount> <tirne> 
Enter Amount <time> 
Form Message <type> 

Show Response <encrypted response> <time> 
Reset 

1.3.2, BIA Software: CATV (Integrated lemote) Command Set 

The BJACATV software interface exports a command set that 
allows terminals integrated with a Phone/CATV BIAs to interact with the 
system. The following operation is supported: 

Remote Transaction Authorization 
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In order to implement that operation, the BWCATV provides the 
following command set: 

Get Biometric <tirae> 
Set PIC <text> 

Assign Register <register> <text> 
Set Account index code <text> 
Form Message <type> 

Decrypt Response <encrypted response raessage> 
Reset 

U*3. BIA Software: Integrated FAX Command Set 

The MA/Fax software interface exports a command set that 
allows terminals integrated with a fax BIA to interact with the system. The 
following operations are supported: 

Secure Fax Submit 
Secure Fax Data 
Secure Fax Tracking 
Secure Fax Retrieve 
Secure Fax Reject 
Secure Fax Archive 
Secure Fax Contract Accept 
. Secure Fax Contract Reject 
Electronic Document Archive Retrieve 

in order to implement these operations, the BIA/Fax provides 
the following command set: 

Get Biometric <time> 

Set PIC <iext> 

Set Title Index Code <text> 

Assign Register <regtster> <vaiue> 

Get Message Key 
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Form Message <type> 

Decrypt Response <encrypted response message> 
Reset 

1.3,4. BIA Software: Registration Command Set 

The BIA/Reg software interface exports m interface that allows 
general purpose computers to interact with the system to identify and 
register individuals. The following operations are supported: 

Individual Identification 
Bioraeuic Registration 

in order to support those operations, the BIA/Reg provides the 
following command set: 

Set Language <ianguage~nai»e> 

Get Bsometric <time> [primaryjsecondary] 

Get PIC <time> 

Assign Register <register> <text> 
Get Message Key 
Form Message <type> 

Show Response <encrypted response> <time> 
Reset 

13.5. BIA Software; PC Command Set 

The BIA/PC software interface exports a command set that 
allows general purpose computers to send, receive, and sign electronic 
documents, conduct transactions across the network, and provide 
faiometric-derived credentials to sites on the network. The following 
operations are supported; 

Electronic Document Submit 
Electronic Document Data 
Electronic Document Tracking 
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Electronic Document Retrieve 
Electronic Document Reject 
Electronic Document Archive 
Electronic Document Archive Retrieve 
Electronic Signature Submission 
Electronic Signature Check 
Remote Transaction Authorization 
Network Credential 
Secured Connection 

In order to support those operations, the BIA/PC provides the 
following command set- 



Get Biometric <time> 

<3etMC<time> 

Get Account index code <time> 

Validate Amount <amoum> <time> 

Enter Amount <time> 

Validate Document <name> <time> 

Assign Register <register> <text> 

Get Message Key 

Form Message <type> 

Show Response <encrypted response> <f ime> 
Validate Private <encrypted validation> <ttme> 
Reset 

1.3.6, BIA Software: Issuer Command Set 



The BIA/Iss software interfere exports an interface that allows 
general purpose computers to interact with the system to authenticate and 
submit batch change requests. The following operation is supported- 




issuer Batch 
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In order to implement this operation, the BLMss provides the 
following command set; 

Set Language <ianguage-name> 

Get Biometric <tane> [primaryjsecondaryj 

Get PIC <time> 



ster <register> <value> 
Get Message Key 
Form Message <type> 

Show Response <encrypted response <tirae> 
Reset 

1.3.7. MA Seftware- Internal Command Set 

The BIA/Int exports a command set that allows general 
computers to interact with the system to identify tedmdmk The 
following operation is supported: 

Individual Identification 



to order to implement this operation, the BIA/im provides the 
following command set: 



Set Language <ianguage-name> 
Get Biometric <time> 
Get PIC <time> 

Assign Register <register> <value> 
Get Message Key 
Form Message <type> 

Show Response <eocrypted response^ <time> 
Reset 

1.3.8, BIA Software; ATM Command Set 

The BIA/ATM software interface exports a command set that 
allows ATMs to identify individuals The following operation is supported; 
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Account Access 

U order to implement this operation, the BIA/ATM provides 
the following command set; 

Get Blometric <ttrae> 
SetPIC<text> 

Set Account index code <text> 
Assign Register <register> <vaiue> 

Form Message <type> 

Decrypt Response <sncrypted response message> 
Reset 

1.4, Terminals 

1.4.1. Intfotiuction 

The terminal is the device that controls the BIA and connects to 
the DPC via modem, X.25 connection, or Internet connection — methods 
well-known to the industry. Terminals come in different shapes and sizes, 
and require different versions of the BIA to perform their tasks. Any 
electronic device, which issues commands to and receives results from the 
biometric input device, can be a terminal. 

Some terminals are application programs that run on a general 
purpose microcomputer, while other terminals are combinations of special 
purpose hardware and software. 

While the terminal is critical for the funttioning of the system as 
a whole, the system itself places no trust in the terminal whatsoever. 
Whenever a terminal provides information to the system, the system always 
validates it in some manner, either through presentation to the individual 
for con&roauon, or by cross-checking through other previously registered 
information. 

While terminals are able to read some parts of BIA messages in 
order to validate that the data was processed properly by the BIA, 
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tennoials cannot read biometric identification information meluding the 
biometric, the PIC, encryption keys, or account index codes. 

Specific BIAs export some security functionality to the 
terminal, such as PIC entry, and private code display. As a result, such 
devices am regarded as somewhat less secure than their entirely 
self-contained counterparts, and as such have consequently lower security 
ratings. 

There are many different terminal types; each is connected to a 
specific model BIA. Each terminal is described in brief below: 

ATM {Automated Teller Machinery) 

Integrated BIA/ATM with ATM software load provides 
biometric-PIC access to ATM cash dispensers. 

BUT (Bioaietric Registration Terminal) 

Standard BIA with Registration software load attached to a 
microcomputer provides banks whh the ability to register new 
mdividuais with the system along with their financial asset accounts and 
other personal information. 

GET (Certified Email Terminal) 

Standard BIA with PC software load attached to a 
microcomputer provides individuals with the ability send, receive, 
archive, reject, and track certified email messages. 

CFF (Cabie-TV Point of Sale Teraiaai) 

BIA/eatv with CATV software load attached to the CATV 
broadband provides individuals with btometric-teievision (or "TV") 
remotes with the ability to authorize television shopping purchases. 

CST (Customer Service Terminal) 

Standard BIA with Internal software load attached to a 
microcomputer system authorizes employees to construct database 
requests for the purposes of customer service. 
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EST (Electronic Signature Terminal) 

Standard BIA with personal computer software load attached to 
a microcomputer provides individuals with the ability to construct and 
verify electronic signatures on documents. 

EPT (Internet Point of Sale Terminal) 

Standard BIA with personal computer software load attached to 
a microcomputer provides individuals with internet connections the 
ability to purchase products from a merchant that is connected to the 
internet. 

IT (Issuer Terminal) 

Standard BIA with Issuer software bad attached to a 
microcomputer provides hanks with the ability to send batched changes 
of asset accounts to the DPC. 

ITT (Internet Teller Terminal) 

Standard BIA with personal computer software ioad attached to 
a microcomputer with an internet connection provides individuals with 
the ability to perform transactions with their favorite Internet Bank. 

PPT (Phone Point of Sale Terminal) 

BIA/'catv with CATV software bad integrated with a telephone 
provides individuals with the ability to authorize transactions over the 
telephone, 

RPT (RetaU Point of Sale Terminal) 

Standard BIA with Retail software load attached to an X.25 
network or using a modem allows an individual to purchase items using 
transaction authorizations in a store. 

SFT (Secure Fax Terminal) 

BlA/catv with Fax software load integrated with a fax machine 
provides individuals with the ability to send, receive, reject archive, and 
track secured fax messages. 
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1.4.2. Terminal: Retail Point of Sate Terminal 
1.4.2,1. Purpose 

Hie purpose of the RPT is to allow ra&viduals to purchase 
items at a store without having to use either cash, check, or a debit or 
credit card. 

The RPT uses a BIA/Retaii to authorize financial transactions 
from an individual to a merchant. In addition to being used to accept 
biametric-Pie authorizations, the RPT provides standard debit and credit 
card seaming functions as weii 

Mote that only the biometric-reiated transactions are described 
in detail here. It is assumed that the RPT wffl also consist of standard 
credit and debit magnetic stripe card readers, as well as optional smart card 
readers too. 

1.42.2, Cons traction 

Each RPT is connected to the DPC by a modem, an X.25 
network connection, an ISDN connection, or similar mechanism. The RPT 
may also be connected to other devices, such as as electronic cash register, 
from which it obtains the amount of the transaction and the merchant code. 

The RPT consists of: 

* an BIA/Retaii 

* an inexpensive microprocessor 

* 9,6 kbmodem/X,25 network interface hardware 

* merchant identification code number in aon-voiatite RAM 

* a DTC serial port for connecting to the BIA 

* magnetic stripe card reader (known in the industry) 

* £CR (electronic cash register) connection port 

* optional smart card reader (known in the industry) 
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1.4.23. Mentfficatten 

Two entities need to be identified for the DPC to respond 
positively to an BIA transaction authorization request: the individual, and 
the merchant. 

The kdividyal is identified by the biometric-PIC, and the 
merchant is identified by the DPC, which cross-checks the merchant code 
contained in the BIA's VAD record with the merchant code added to the 
transaction request by the RPT. 

1.4.2,4, Operation 

First, the merchant enters the value of the transaction into his 
electronic cash register. Then, the tadividuai enters Ms biometric-PIC, bis 
account index code, and then validates the amount. The RPT then adds the 
product information and the merchant code to the BIA, instructs the BIA 
to construct the transaction, and then sends the transaction to the DPC 
through its network connection (modem, X.25, etc). 

When the DPC receives this message, it validates the 
biometrie-PIC, obtains the account number using the index code* and 
cross-checks the merchant code in the message with the registered owner 
of the BIA. If everything checks out, the DPC forms and sends a 
credit/debit transaction to execute the exchange. The response from the 
credit/debit network is added to the private code to form the transaction 
response message, which the DPC then sends back to the RPT. The RPT 
examines the response to see whether or not the authorization succeeded, 
and then forwards the response to the BIA, which then displays the 
individual's private code, concludina the transaction. 

1.4X5. Security 

Messages between the RPT and the DPC are secured by 
encryption and MAC calculation from the BIA. The MAC allows the RPT 
to review the unencrypted parts of the message, but the RPT cannot 
change them. Encryption prevents the encrypted pan of the message from 
being disclosed to the RPT. 
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Each mail BIA must be registered to a merchant This helps to 
AscourageBIAtheft. Furthermore, because the RPT adds the merchant 
code onto each message, replacing a merchant's BIA with a different BIA 
is detected by the cross-check performed at the DPC. 

J.4.3. Termiaal: internet Point of S&ie Terminal 

1.4.3. J. Purpose 

The purpose of an internet Point of saie Terminal (IPT) is to 
author^ credit and debit financial transactions from an individual at a 
computer to a merchant, both of whom are on the Internet. 

Note that the internet simply represents a general purpose 
network where a merchant, the DPC, and the IPT can ail connect to each 
other m real time. As a result, this mechanism would work exactly the 
same on any other general purpose network. 

1.43.2. Construction 

The JPT consists of: 

* an BIA/PC 

♦ a microcomputer 

* an internet Shopper software application 

• an internet (or other network) connection 

1.4.3.3. Idetitiftcaiioa 

In addition to identifying the individual, the IPT must also 
identify the remote merchant who is the counterparty to the transaction. 
The mercnam must also identify both the DPC and the IPT. 

The internet Shopper program stores the hostname (or other 
form of net name) of the merchant from which the purchase is takins place 
m order to verify the merchant's identity. Since the merchant renters all 
of his legitimate internet hosts with the DPC. this allows the DPC to 
cross-check the merchant code with the merchant code stored under that 
hostname to verity the merchant's identity. 
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1.43.4. Operation 

First, the IPX connects to the merchant using the internet. 
Once a connection is established, the IPT secures it by generating and then 
sending a Session Key to the merchant. In order to assure that the session 
key is protected from disclosure, it is encrypted with the merchant's Public 
Key using Public Key Encryption. When the merchant receives this 
encrypted Session Key, he decrypts it using his Private Key. This process 
is called securing a connection through a Public Key Encrypted secret key 
exchange. 

Once connected, the IPT downloads the merchant code, and 
both price and product information fiora the merchant. Once the individual 
is ready to make a purchase, he selects the merchandise he wishes to buy. 
Then, the individual enters the biometric-PIC using the BIA/PC, the JPT 
sends the merchant code, the product idenrificatioa information, and the 
amount to the BIA, and instructs it to construct a Remote Transaction 
Authorization request. Then the IPX sends the request to the merchant via 
the secure channel. 

The merchant is connected to the DPC via the same sort of 
secure connection that the IPT has with the merchant, namely, using Public 
Key Encryption to send a secure session key. Unlike the IPT- merchant 
connection, however, merchant~DPC session keys are good for an entire 
day, not for just one connection. 

The merchant connects to the DPC, securing the connection 
using the session key, forwarding the transaction to the DPC for validation. 
The DPC validates the bioraetrie-PIC, cross-checks the merchant code 
contained in the request with the merchant code stored under the hostname 
that was sent in the request, and then sends a transaction to the credit/debit 
network. Once the credit/debit network responds, the DPC constructs a 
repiy message including the credit/debit authorization, an encrypted private 
code, and the addre ss of the individual, and sends that messag e back to the 
merchant 

Once the merchant receives the repiy, it copies the individual's 
mailing address out of the repiy, makes note of the authorizat ion code, and 
forwards the repiy message to the IPT. 
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The IPT hands the reply to the BIA, which decrypts the private 
code and displays it on the LCD screen, indicating that the DPC record 
the ^dividual The IPT also shows the resul t of the transaction as well be 
it success or failure, 



1.4.3.5. Security 



Since the system in general assumes that an adversary inhabiting 
the network can Mjack network connections at any point, aH parties must 
have secure cornmumcatior^ dtiring their realtime interactiom. The mam 
concern isnt disclosure of information, but rather insertion or redirection of 



The whoie system of Public Key Encryption relies on having a 
trusted source for the Public Keys, These trusted sources are called 
Certifying Authorities, and we assume that such a source will be avaiiable 
on the Internet in the near future. 

1.4,4. Terminal: loteraet TelJer Terminal 
1.4,4.1. Purpose 

The Internet Teller Terminal (ITT) is used to identifv 
individuals for internet banking sessions. The DPC, the bank's computer 
system, and the individual are ail connected to the Internet. 

There are two main tasks. The first is providing a secure 
communications channel from the ITT to an internet bank. The second is 
prowdiog unimpeachable identity credentials to the internet bank Once 
both are accomplished, the ITT can provide a secure internet banking 
session. In addition, the BIA's chalienge-response verification capable is 
used to provide additional security for ail high-value and/or irregular ' 
transactions. 
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1.4.42. Construction 



The ITT consists of: 

• an BIA (standard PC mode!) 

• a microcomputer 

• an internet Teller software application 

• an internet connection 

The ITT accepts biometric identification using an BIA/PC 
connected to the microcomputer serving as the individual's Internet 
terminal. 

1.4.4.3, Identification 

Both the individual and the bank are identified by the DPC to 
create the network credential. The network credential includes the 
individual's ideatification as well as the context of the connection (i.e., the 
TCP/IP source and destination ports). 

The DPC identifies the bank by cross-checking the code that 
the bank sends to the ITT with the bank's hostname that the ITT sends to 
the DPC . 

1.4.4.4. Operation 

First, the ITT connects to the internet bank, making sure that 
the bank has the computing resources required to handle a new session for 
the individual. If the bank has sufficient resources, it sends back the bank 
identification code to the ITT. 

Once connected, the ITT instructs the BIA to obtain the 
biometric-PIC and the account index code from the individual. Then the 
ITT adds both the bank's hostname as well as the bank code. Using all this 
information, the BIA is then asked to form a network credential request 
message which the ITT sends to the DPC via the Internet. 

When the DPC receives this message, it validates the biometric- 
PIC, obtains the account number using the index code, and makes sure that 
the bank code from the message matches the bank code stored under the 
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bank's hostname in the Remote Merchant database. The DPC also checks 
to make sure that the account number returned by the index code belongs 
to the bank as well If all checks out, then the DPC creates a network 
credential using the individual's account identificatioa the time of day and 
the bank code. The DPC signs this credential using Public Key Encryption 
and the DPC, Private Key. The DPC retrieves the bank's puttie kev and 
the odividuaft private code, and with the credential forms the network 
credenttai response message. The response message is encrypted using the 
BIA response key, and is then sent back to the ITT. 

When the ITT receives the response, it hands the response 
message to the BIA. The BIA decrypts and then displays the individual^ 
pnvate code on the LCD screen. The bank's public kev is stored in the 
Puhfac Key register. Two random session keys are generated by the BIA. 
The first key, called the Shared Session Key, is revealed in plaintext to the 
ITT. The ITT uses this shared session key to secure the connection with 
the bank. 

The other session key, called the Private Session Key is not 
shared with the ITT. It is used for the BIA's c 



mechanism, a mechanism that allows the bank to obtain specific validation 
for non-routine transactions straight from the individual, without involving 
the (untrustworthy) ITT. 

After receiving the Shared Session Key, the ITT asks the BIA 
to form a Secure Connection Request message, which includes both 
session keys and the network credential, and are all encrvmed with the 
bank's public key. The ITT then sends the Secure Connexion Request 
message to the bank. 

When the bank receives the request message, it decrypts the 
message using its own Private Key. Then, it decrypts the actual network 
credenttai using the DPCs public key. If the nerwork credential is valid 
and has not expired (a credential times out after a certain number of 
minutes), the individual is authorized, and the conversation continues, with 
the session key used to ensure security. 

Whenever the individual performs any non-routine or 
high-value transactions, the bank may wish to ask the mdividuai to ydiim^ 
those transactions for extra security. To do so, the bank sends a 
challenge-response message encrypted with the Private Session Key to the 
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ITT, which forwards that challenge-response message to the BIA. The 
BtA decrypts the message, displays the challenge (usually of the form 
"Transfer of $2031.23 to Hick Adams OK?"), and when the individual 
validates by hitting the OK button, the BIA re-encrypts the response with 
the Private Session Key and sends that message io the ITT, which forwards 
it to the bank, validating the transaction. 

1.4,4,5. Security 

The system makes use of publi c key cryptography to both 
provide credentials and to secure commtmications between the ITT and the 

bank. 

For this mechanism to &nction properly, the bank must know 
the DPCs public key, and the DPC must know the batik's public key. It is 
critical to the security of the system that both parties keep the respective 
pubic keys secure from unauthorized modification. Note that public keys 
are readable by anyone, they just cannot be modifiable by anyone, Of 
course, any session or secret keys must be kept secure from observation, 
and those secret keys must be destroyed after the session has ended. 

The extra validation step for non-routine transactions is 
necessary because of the relative difficulty involved in securing personal 
computer applications on the Internet due to viruses, hackers, and 
individual ignorance. Banks should probably restrict routine money 
transfers available to ITT's to include only money transfers to well-known 
institutions, such as utility companies, major credit card vendors, and so 
on. 

1.4.5. Terminal: Electronic Signature 
1.4.5.1. Purpose 

The electronic signature terminal (EST) is used by individuals 
to generate electronic signatures that cannot be forged for electronic 
documents, The EST either allows individuals to sign electronic 
documents, or verifies electronic signatures already on such documents. 
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I.4.S.2. Construction 

The EST consists of; 
aaBIAK 

* a microcomputer 

* a message digest encoder algorithm 

* a modem, an X.25 connection, or an Internet connection 

* an electronic signature software application 

The EST uses an BIA/PC attached to a microcomputer, with 
events controlled by an electronic signature software application. 

1.4,5*3* Identification 

To create a digital signature without using some sort of 
public/private keyed token, three things need to he done. First, the 
document to be signed needs to be uniqtidy identified, the time of day 
needs to be recorded, and the individual performing the signature needs to 
be identified. This ikiks the document, the individual, and the time, creating 
a unique time stamped electronic signature. 

1.4.5.4. Operation 

First the document to be signed is processed by a message 
digest encoding algorithm that generates a message digest code. One such 
algorithm is the MD5 algorithm by RSA, which is well known in the 
industry. By their nature, message digest algorithms are specifically 
designed so that it is almost impossible to come up with another document 
that generates the same message digest code. 

Then, the individual enters his biomarie-PIC using the BIA, the 
message digest cod e is handed to the BIA, the name of the docum ent is 
added, and the resulting Digital Signature request message is sent to the 
DPC for authorization and storage. 

When the DPC receives the request, it performs a biometrie 
identity check, and once the individual is verified, it collects the message 
digest encoding, the mdividuai's biometrie account number, the current 
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time of day, the name of the document, and the identification of the BIA 
that gathered the signature, and stores them all in the Efecir orac Signatures 
Database (ESD), The DPC then constructs a signature code text string 
that consists of the ESD record number, the date, the time, and the name of 
the signer, and sends this signature code along with the individual's private 
code back to the EST. 

To check an electronic signature, the document is sent through 
the MD5 algorithm (known in the industry), and the resulting value 
together with the electronic signature codes are given to the BIA along 
with the requesting individual's biometric-PIC, and the message is sent to 
the DPC, The DPC checks each signature for validity, and responds as 
appropriate, 

1.4.5.5. Security 

The BIA doesn't encrypt any of the data relating to electronic 
signatures, so document titles along with specific MD5 values are sent in 
plaintext. The same situation holds true for signature validations. 

Thus while signatures cannot be forged, some of the details 
excluding document names) are vulnerable to interception. 

1.4.6. Terminal: Certified Email Terminal 

L4.6-I. Purpose 

The purpose of the Certified Email Terminal (CET) is to 
provide individuals a way of delivering electronic messages to other 
individuals in the system while providing for identification of sender, 
verification of both receipt and recipient, and assuring confidentiality of 
message delivery . 

The CET uses a BIA/PC to identify both the sender and the 
recipient. Security is established by encrypting the message, and then by 
encrypting the message key using the sender's BIA during the upload, and 
then decrypting the message key using the recipient's BIA during the 
download. 
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1.4.6.2, Construction 

Both the transmitter and the recipient CBT consists of 
aBIA 

a microcomputer 

a modem, an XZS connection, or an Internet connection 
the ability to receive email 
a certified electronic maii application 

A CET is actually a microcomptiter with an electronic mail 
apphcat.cn and a network connection which invokes the BiA to generate 
btometnc-PIC authorizations to send and receive certified electronic maii. 

1.4,3.3. Identification 

In order to guarantee delivery of the message, both sender and 
recipients must be identified. 

The sender identifies himself using his biometrie-PIC when he 
upioadsthemessagetotheDPC. Each recipient the sender wishes to send 
the document to is identified either by bfametric account identification 
number, or by fax number, and extension. In order for a recipient to 
download the message, he identifies hiimelf using his biometric-PIC. This 
procedure resembles a person-to-person telephone call. 

1.4,6.4, Operation 

Message delivery starts with an individual uploading a 
document or message, and identifying himself using Ms biometric-PIC 
Toe ^dividual then verifies the name of the document, and the email 
message is encrypted and uploaded. 

Once a message is uploaded, the sender receives a message 
Verification code that can be used to request the current delivery status of 
the document to each of the recipients. 

The DPC sends an electronic maii message to each recipient 
notifying them when a certified message has arrived. 
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Once the recipient receives the notification, the recipient may at 
Ms leisure either choose to accept or refuse that message or a group of 
messages by submitting Ms biometric-PIC and having it validated by the 
DPC. 

Once successfully transmitted to ail recipients, a document is 
removed after a predetermined period, generally 24 hours. Individuals 
wishing to archive the document, along with an mdication of all of the 
individuals to whom the message was sent may submit message archival 
requests prior to the deletion of the message. 

1,4.6.5. Security 

la order to effect the secure aspect of the transmission, the 
document is protected from disclosure en route. The CET accomplishes 
this using the 56-bit Message Key generated by the BIA. Since the BU 
takes responsibiiity for encrypting the Message Key as part of the 
biometric-PIC, the encryption key is securely sent to the DPC. 

When an individual downloads the message, the message key is 
sent encrypted along with the private code, to allow the recipient to 
decrypt the message. Note that it is fine to have all recipients have tMs 
message key, as they all receive the same message. 

As with the ITT, individuals must take care to secure their CET 
application software from surreptitious modification, as a modified CET 
can send any document it wishes to once the individual validates the 
document name. 

1.4.7, Teimiaak Secure Fax Terminal 

1.4.7,1. Purpose 

The purpose of the secure fax terminal (SFT) is to provide 
mdividuais a way of delivering fax messages to other individuals in the 
system while providing for identification of sender, verification of both 
receipt and recipient, and assuring confidentiality of message delivery. 
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Each SFT uses an integrated BIA/catv to identify both the 
sender and the recipient. Cornnmmcations security is accomplished 
through encryption. 

1.4.7.2. Coastractioo 

Both the transmitter and the recipient SFT consists of: 

* an BIA/catv 

* a fax machine 

* optional ISDN modem 

A SFT is a fax machine connected to the DPC via a modern 
The system treats faxes as just another type of certified electronic mail. 

1.4.7.3. Identification 

There are several different levels of security for secure faxes 
but m the most secure version, the identity of the sender and all recipient 
is verified. 

The sender identifies himself using his hiometric-PIC and title 
index code when he sends his message to the DPC, To nick up the fax, 
each recipient listed identifies nunself, again using foiometric- HC and title 
index code. 

In addition, the receiving site is identified by phone number 
This phone number is registered with the DPC. For secured- confident 
faxes, each recipient is identified with the phone number and the extension. 

1,4.7*4, Operation 

There are five basic types of faxes that an SFT can send. 
1 Unsecured Faxes 

Unsecured faxes are equivalent to a standard fax. The sender 
enters the phone number of the recipient site, and sends the fax In this 
case, the sender remains unidentiled, and the fax is sent to a mm phone 
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number m the hopes that it will be delivered to the proper recipient. An 
SFT marks the top line on ail such unsecured faxes prominently as being 
"UNSECURED**, AH faxes received from oon- SFT fax machines are 
always marked as being unsecured. 

IL Sender-Secured Faxes 

In a sender-secured fax, the sender selects the "sender- 
secured" mode on the fax machine, enters their biometric-PIC followed by 
their title index code. The fex machine then connects to the DPC, and 
sends the biometric-PIC information. Once the DEC verifies the 
individual's identity , the individual then sends the fax by feeding the 
document into the fax scanner. In this case, the fax is actually sent to the 
DPC, which stores the fax digitally. Once the entire fax arrives at the DPC, 
the DPC commences sending the fex to each destination, labeling each 
page with the name, title, and company of the sender, along with the 
banner of "SENDER^CURED" at the top of each page. 

HI Secured Fax 

In a secured fax, the sender selects the "secured" mode on the 
fax machine, enters their biometric-PIC followed by their title index code, 
and then enters the phone numbers of the recipients. Once the system 
verifies the sender's identity and each of the recipients phone numbers, the 
individual then sends the fax by feeding the document into the rax scanner. 
The fax is then sent to the DPC, which stores the fax digitally. Once the 
entire fax arrives at the DPC, the DPC sends a small cover page to the 
destination indicating the pending secured fax, the sender's title and 
identity, as well as the number of pages waiting, along with a tracking 
code. This tracking code is automatically entered into the memory of the 
recipient's fax machine. 

To retrieve the fax, any employee of the recipient company- 
can select the "retrieve fax" button on his fax machine, select which 
pending fax to retrieve by using the tracking code, and then enter 
biometric-PIC. If the fax is unwanted, the individual may press the "reject 
fax" button, though he must still identify himself to the system in order to 
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do this. Once validated as a member of the company, the fee is then 
downloaded to the recipient's fax machine. Each page has "SECURED" on 
the top of each page, along with the sender's identity and title information. 

IV, Secured Confidential Fax 

In a secured-confidemial fax, the sender selects the 
"secured-confidendal" mode on the fax machine, enters his biometric- PIC 
followed by his title and index code, and then enters the phone number and 
system extension of each recipient. Once the DPC verifies the sender's 
identity and each of the recipients phone numbers and extensions, the 
mamdual then sends the fax by feeding the document into the fax scanner 
The fax is sent to the DPC, which stores the fax digitally. Once the entire 
tax arrives at the DPC, the DPC sends a small cover page to each 
deputation indicating the pending secured- confidential fcx, the sender's 
title and identity, the recipient's title and identity, as well as the number of 
pages waittng, along with a tracking code. This tracking code is 
automatically entered into the memory of the recipient's fax. However the 
only mdrvidual that can retrieve the fax is the individual whose extension 
code is indicated. 

This individual selects the "retrieve fax" button, selects the 
pending fax to retrieve, and then enters his biometric-PIC. Once validated 
as the recipient, the fax is then downloaded to the recipient's fax machine 
Each page has " SECURED-CONFIDENTIAL " on the top of each page, 
along with the sender's title and identity information. 

V. Secured Confidential Contract Fax 

This fax is processed identically to the secured- confidential fax 
m terms of the actual delivery of the fax to the recipients, except that the 
fax u uded "contract" instead of secured- confidential. In addition, the 
DPC automatical archives contract faxes. Any recipient mav accept or 
reject the contract through the SFT subsequent to receiving the contract 
fax. Hence with the opuon, the DPC performs the role of an electronic 
notary. 
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Any fax that. is sent to the system and then forwarded to the 
recqm may be sent to any number of recipients without tying up the 
senotegfkxmachine. Additionally, the tracking number of any fax sent is 
entered mto the memory of the fax machine; a status report on any ongoing 
fax can be generated at the sending machine by selecting the "status* 
button and then selecting the particular fax pending tracking code The 
DPC issues a report that is immediately sent to the sending fax machine 
detailing the state of the sending for each recipient. 

With any secured or secured-eonfidentiai fax, an option exists 
for either the sender or one of the recipients to archive the fax (along with 
the speafes as to who seat and received the fax) for future reference. To 
this end, any secured fax is retained for some time period (i.e., 24 hours) 
following successful delivery. An archival tracking code is returned to the 
ndiviAial whenever an archive is requested. This archival code is used to 
retrieve faxes and fax status reports archived with the system. 

Archived fetes are placed on read-only secondary sf orase after 
some time period (Le., 24 hours). Retrieving an archived fax requires 
human mterventfcn, and may take up to 24 hours to perform. 

i.4.7,5. Security 

The SFT system works hard to assure the recipient of the 
sender's identity, and it works just as hard to assure the sender that the 
recipient actually acknowledged receipt of the document. 

In order to protect against interception of the communications 
between the sender and recipient, the fax terminal encrypts the fax using 
the Message Key facility provided by the BIA Since the BIA takes 
responsibility for encrypting the Message Key as part of the biomemc-FIC, 
the encryption key is securely sent to the DPC. 

When an individual receives a secured rax of any type, the 
message key is sent encrypted along with the private code, to allow the 
recipient to decrypt the message. Note that it is fine to have all recipients 
have this message key, as they ail receive the same message. 
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1.4,7.6. Notes 

Sending secured faxes is very Mar to sending electronic maO, 
and reuses much of the same software. 

It is possible to construct fax tenranais that do not have 
mtegral BIA/fax devices tot that have a port suitable for attaching m 
external BIA/pc and software appropriate for using the BIA. 

1,4.8, Terminal: Biometric Registration Terminal 
1*4.8.1, Purpose 

The purpose of the Biometric Registration Terminal (BRT) is to 
register new individuals including their biometric-HC, mailing address, 
Pnvate dectronic «»* ad^es, a list of titles and title index codes 
used to send and receive electronic messages and faxes, and a list of 
Snanaal asset accounts and account index codes that they can access all 
using their biometric-PIC. 

The objective of the enrollment process is to obtain personal 
mtommtion from an individual at the location of a responsible institution 
where that information can be validated. This deludes, but is not limited to 
retail banking outlets, and corporate personnel demnmems. Each 
paraapating responsible institution has one BRT that is used bv a aroup of 
employees who have been authorized to perform registrations. Each 
employee is accountable for each individual registered. 

1.4.8.2. Construction 

an microcomputer and screen, keyboard, mouse 
» an BIA/Reg 

9.6 kb modem/X.25 network connection (known in the industry) 
» a biometric registration software application 

The BRT uses an attached BIA/Reg for biometric entry and is 
connected to the system by a 9.6kb modem or an X.25 network connection 
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(known: in the industry). Biometric registration teixmnals are located in 
places that are physically secure such as retail banking outlets. 

1.4.8J. Identification 

Three entities need to be identified for the DPC to respond 
positively to an BIA/Reg registration request: the registering employee, 
the institution, and the BIA/Reg. The employee must have been authorized 
to register individuals for that institution. 

The institution and the BIA are identified by cross-checking the 
owner of the BIA with the institution code set by the BRT. The employee 
identifies himself to the system by entering his biometric- PIC upon 
starting the registration application. 

The institution uses its standard customer identification 
procedure (signature cards, employee records, personal formation, etc) 
before registering the individual on the system. It is important for the 
institution to verify ^dividual identity as assiduously as possible, since the 
registering individual will be empowered to transfer money from those 
accounts at will, and/or send electronic messages using the name of the 
company. 

1.4.8.4. Operation 

During registration, the individual enters both a primary and 
secondary biometric. The individual must use both index fingers; if the 
individual is missing index fingers, the next inner-most ringer may be used. 
Requiring specific fingers to be used allows the prior fraud check to work 

The individual is encouraged to select a primary and a 
secondary finger; the primary finger is given preference during the DPC 
identity check, so the individual should present the most-often used finger 
as the primary. Of course, the DPC could choose to alter the designation 
of primary and secondary biometrics based on operations if it turns out to 
be important to do so. 

As a part of the biometric encoding process, the BIA/R 
determines if the individual has entered "a good print." Note that there are 
some individuals whose jobs result in the accidental removal of their 
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tmgerpnnts, such as individuals who work with abrasives or acids 
bnfenunatdy, these individuals cannot use the system. Thev are detected 
at th» stage in the process and informed that they cannot participate 

r„ J"" Se5e< " S 2 HC ° f fr ° m f0ur t0 Weive ^ a 

senes of PIC opaons provided by the system's central database. However 

thePICmustbevaJidatedfaythesystem. This involves two checks- one ' 
that the number of other individuals using the same PIC arent too Great ' 
(smce the PIC is used to reduce the number of individuals checked by the 
btometnc comparison algorithm) , and that the individual being reared 
iat too "close", biometricaiiy speaking. with other individuals wiin the 
same PIC group. If cither happens, the enrollment is rejected, an error 
message * returned to the BRT, and the individual is instructed to request 
a different PIC. The system may optionally return with an "identical ' 
match" error condition, which indicates that the individual already has a 
record in the system uader that PIC. 

A PIC of 0 allows the system to assign a PIC to the individual 
The individual constructs a confidential private code consisting 
ofawordorphrase. If the individual does not wish to construct one a 
private code will be constructed randomly by the terminal. 

The individual may also arrange their financial asset code list 
This fast describes which account index code points at which account (i e I 
for debit, 2 for credit, 3 for emergency debit, etc). Note that this can oniv 
occur rf the registering institution is a bank, and only if the accounts are' 
owned by that particular banking institution. 

Even after registration, an individual is not actually able to 
perrorm operations using the system until a prior fraud check is comoieted 
Thts generally takes a few minutes, but during times of high load it takes ' 
up to several hours. Only if the system finds no instance of prior fraud is 
the individual's account activated. 

1.4.8.5. Security 

If an individual is found to have defrauded the system even 
once, the DPC institutes a database-wide involuntary biomemc database 
search tor the criminal Several of these are performed each night, so 
odrirfu* who are particularly wanted by the system are winnowed out of 
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the database by using a time consuming process during conditions of %k 
aatvity. 

The employees performing the registration operation identify 
themselves using biometric-PIG only when initially activating the 
registration system. This is a convenience for the employee, but a possible 
security problem for the system, as unattended or "temporarily borrowed" 
BRTs could be the source for fraud. As a result, the registration 
application exits after a predetermined period of no activity, 

L4.9. Terminal: Customer Service 

1.4.9.1. Purpose 

The purpose of the customer service terminal (CST) is to 
provide internal DPC support personnel access to the various aspects of 
the system databases. Support people need to answer inquiries by 
individuals, issuers, institutions, and merchants that are having trouble with 
the system, 

1.4.9.2. Construction 

The CST consists of; 
» a microcomputer 

• anBIA/Int 

• ethernet/token ring/FDDI network interface 

• a database e?aratuiation and modification application 

Each CST is connected to the system via a high speed iocs! area 
network connection such as token ring, etheraet, fiber (FDD!), etc. Each 
CST has the capability to query each of the databases, and display the 
results of these queries. However, the CST only displays fields and records 
based on the privilege of the individual terminal user. For instance, a 
standard customer service employee won't he able to see the encryption 
code for a given BIA's VDB record, though they can see which merchant 
or individual currently owns that 8 LA. 
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1,4*9.3. Identification 

For the CST to allow access to the database, the individual and the BiA 
mn* be identified by the system. Ia addition, the fafividaaft privilege level 
must also be determined, so that the database can restrict access 
appropriately. 

1.4.9.4. Operation 

An individual using a CST starts a session by providing 
identification by entering their biometric-PIC. The BIA constructs an 
Identification Request message, and send it to the DPC for verification 
Once the system verifies the individual the CST application can operate 
normally, though fasted by the individual's previously assigned DPC 
privilege level 

1.4.9.5. Security 

For security purposes, the DPC will terminate a connection to 
the CST application after a predetermined idle time period. 

It is important that the database application cannot be modified 
in any manner, either deliberately, or through an unintentional introduction 
of a virus. To that end. individual CSTs do not have any floppy drives or 
other removable media. Furthermore, read access to the database 
application executable is strictly limited to those with a need to know. 

In order to protect the communications between the CST and 
the database from surreptitious modification or disclosure, the CST 
encrypts all traffic between the CST and the database. To do this, the CST 
generates a session key that is sent to the server during the login session 
with the system. This session key is used to encrypt and decrypt ail 
communications with the DPC that occur during the period. 

Even assuming secure communications and no modified 
database applications, the DPC makes certain that DPC data fields that are 
not accessible to the individual operating the CST are not sent to the CSTs 
database application. Likewise, at no time do any CST personnel have 
access to or permission to modify individual btomemc information. 
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The DPC and the support center can be co-located, or because 
of the fairly tight security surrounding the CST itself, the support center 
can be split off on its own. 

1.410, Termiaal: Issuer Terminal 

14.10.1. Purpose 

The purpose of the issuer terminal is to allow emplovees at 
issuing banks to submit batch asset account modification operations to the 
DPC in a secure and identifiable manner. 

1.410.2. Construction 



The IT consists of; 

• a microcomputer 

* a modem, X.25 network, or Internet connection to the 

* anBlMss 

• a network connection to the bank's interna} network 

The Issuer Terminal uses an issuer BIA to authorise mass 
additions and deletions of financial asset information, 

1,4.10.3. Identification 

In this operation, the bank must be identified, a properly- 
authorized bank employee must be identified, and ail of the individuals 
whose asset accounts are being added or removed must also be identified. 

The bank is responsible for identifying the individuals who wish 
to add their accounts at that bank to their asset account list As in 
biometric registration, this is done by the bank usmg signature cards and 
personal information. The DPC identifies the bank by cross-checking the 
issuer code submitted by the IT with the issuer code registered in the VAD 
record of the BIA/Iss. A biometric-PIC is used to identify the bank 
employee actually submitting the batch. 
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1.4.10.4. Operation 

In order to add a financial asset account, an individual eives his 
biometric identification number to the bank (the identification number is 
given to the individual during the initial biometric registration step) along 
with the accounts that are to be added. After the individual is properly 
identified, this identification code and account list are forwarded to the IT 
for subsequent batch submission to the system. 

Whenever deemed appropriate by the bank, an authorized 
individual at the bank instructs the IT to upload the batched account 
additions/deletions to the DPC. To do this, the authorized individual enters 
his biometric-PIC, the IT adds a session key, adds the bank's issuer code, 
and from that the BIA/Iss constructs an Issuer Batch Request message that 
the IT then forwards to the DPC. The IT encrypts the batch using the 
message code, and then sends that as well. 

When the system receives the Issuer Batch Request, it validates 
that the BlAis an BIA/Iss, that the BIA/Iss is registered to the bank 
claimed by the issuer code, and that the individual identified in the 
biometric-PIC is allowed to submit batch requests to the DPC for that 
bank. If so, the DPC processes ail the requests, keeping track of errors as 
required. Once done, the DPC returns the individual's private code, along 
with an encrypted batch containing any errors that occurred during 
processing. 

1,440,5. Security 

Securing this transaction is critical for the security of the 
system. A criminal intent on fiaud need only find a way to add other 
people's accounts to his biometric identification code and can then commit 
fraud at will. Eventually the criminal is caught, and purged from the 
database, but only after other people's accounts are drained by the criminal. 

Encryption guarantees that the transmission between bank and 
DPC cannot be intercepted, and thus account numbers are protected in 
transit. 

Cross-checking the bank with the BIA/Iss means that both the 
IT and the BIA must be compromised to submit false add/delete messages 
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to the DPC. Thus, the bank must ensure that the IT is physically secure, 
and that only authorized individuals are allowed to access it 

Requiring an individual to submit the hatch provides for a 
responsible human to be "in the loop" whose job it is to make sure that 
proper bank security measures have been followed in the construction and 
submission of the batch, 

1,441. Termiaal: Automated Teller Machinery 
1-4.114, Purpose 

The purpose of the biometric ATM is to provide individuals 
access to cash and other ATM functions without having to use an 
Interbank card. It does this by submitting a biometrie-PIC and an account 
index code and retrieving a bank account number. For users of the 
system, this replaces the Interbank card (known in the industry) + PIC 
mechanism as a method for identifying the account and authorizing the 
individual. It is assumed that all ATMs still continue to accept Interbank 
cards. 

1.441.2. Construction 

» a standard ATM 

* an integrated B1A/ATM (scanner only) 

* a connection to the DPC 

The biometric ATM uses an integrated BIA/ATM to identify 
individuals and allow them access to financial assets using a biometric-PIC 
and an account index. An BIA/ATM is installed bra the ATM, making use 
of the ATMs current PIC pad for PIC and account index code entry. The 
ATM is connected to the system using X.25 or modem. 

The BIA/ATM is structured m such a way as to make 
integration with m existing ATM network as simple as possible. This 
results in a compromise between security and ease of integration. 
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1.4,11.3. Identification 

Three endues need to be identified for the DPC to respond 

The bank is identified by cross-checking the ATMs storM h» t 

itemed through the KMdard biomari^IC. 
1.4.11.4. Operation 

into the B?,""" " ™* id,al «"« ««-*- * 

X^tT """^ wtofch is then sent to the DPC by the 

ATM. ^OPCvahtoesthebio^-PICaswen^theenZ^ 
-"code, -dta.end.u.te^^^^ 
along with the private code back to the ATM 

*»P'^ the pnvate code on AeATMadisplay screen. The ATM also 

account access, or a "duress" account access. If a duress acd, 
«- -heated, the ATM ^pmvye^orrnMeadingint^ 

-varyfromATMtoATM. However, no ATM wili ever provide any 
-canon to the individual , ha, , duress transaction is in progress. 

1,4,11.5. Security 

Messages between the ATM md the DPC are secured by 
^'^MA^ 

ATM cmw change the contents of * message without being detected 
lt i rj Pt, ° n PreVemS ^ enCryPted Pan ° f ^ messa « e W"* ' 
B^theBIA/ATMhasnaLCDornoPICpadattacfaed it 
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from the individual. This is ] ess secure than if the BXA were perfbmiag the 
operation, but as ATMs are generally physically robust, it can probably be 
called a wash. 

1.4.11.6, Notes 

It is between the bank and the individual to specify the behavior 
of an ATM when the individual indicates he is performing a transaction 
under duress. A particular bank may choose to limit access, or alter 
balance herniation, or a false screen may be displayed. A false screen is a 
display of data which has been intenti onally predetermined to be 
inaccurate such that a coercing party will not illegally obtain accurate data 
about an individual's financial assets. It is beyond the scope of the invention 
to specify the precise behavior of an ATM under these circumstances. 

1.4.12, Terminal: Phone Point of Sale Terminal 

1.4.12.1, Purpose 

The purpose of the phone point of sale terminal (PPT) Is to 
authorize credit or debit financial transactions from an individual using a 
specially-equipped telephone to make a purchase from a merchant. 

1.4.12.2. Construction 

The PPT consists of: 

* anBU/carv 

* a rapid-connect digital modern [see the VoiceVlew patent 
(known in the industry)] 

* a telephone (keypad, earpiece, microphone) 

* a microprocessor 

» a DSP (digital signal processor) 
» a standard telephone line 
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The PPT accepts biometrie identification using an BIA/catv 
connected to and integrated with a cordless, cellular, or standard 
telephone. 

1.4.12.3. Identification 

In order for the DPC to authorise a transaction, both the 
individual and the merchant must be identified. 

To identify an individual, Moraetrio-HC identification is used. 

To identify a phone-order merchant, the merchant and all his 
phone numbers that individuals mB call are registered with the DPC. Thus 
when m individual submits an authorization, he also submits the phone 
number he called, which is then cross-checked with the merchant's Msted 
phone numbers, 

1.4.12.4. Operation 

Individuals call merchants that are selling their wares through 
paper catalogs, newspapers, magazines, or other basic print media 
mechanisms. The PPT uses a special modem that shares the telephone 
voice line to exchange digital information with the merchant. 

Each time the individual makes a phone call the PPT keeps 
track of the phone number that was typed by the user, in case the individual 
decides to make a purchase. A DSP is used to detect ciaitone, ring, 
connection, and so on, in order to tell what the actual phone number 
entered was, as distinct from extensions, or the navigation of phone 
message systems, and so on. 

Once a call is placed to a merchant, the salesman for the 
merchant digitally downloads all the reK-vam information to the PPT 
including product, price, and the merchant code. Note that when in 
operation, the modem disconnects the speaker. 

When the product information is downloaded, the PPT then 
prompts the individual for the biometric-PIC, the account index code, and 
then asks the individual to validate the purchase amount. Then the phone 
number and the merchant code are added, and the message is encrypted. 
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The rapid-corineet modem is again engaged to send the authorization 
information to the merchant. 

When the merchant receives the authorization information, the 
merchant verifies that the price and product information are correct, and 
then forwards the transaction to the DPC using a secured coonumatnons 
channel using either the Internet or some other genera! purpose network. 
The connection to the DPC is secured using Public Key Encryption and a 
secret key exchange. 

Upon receiving and decrypting a phone authorization, the DPC 
checks the phone number against the merchant code, validates the 
biomemc-PIC, and then sends the transaction to the credit/debit network 
for authorization. If authorization succeeds, the DPC appends the buyer's 
address to the response message and sends the response to the merchant. 

The merchant receives the response from the DPC, copies the 
mailing address, and forwards the message to the individual again via a 
brief session with the rapid-coimea modem. When the transmission to the 
IPX is complete, a chime sounds, the modem disconnects, and the 
individual's private code (decrypted by the BIA) is displayed on the LCD 
screen. The merchant's sales rep confirms that the individual's mai&g 
address is valid; if so, the call is terminated and the transaction is complete. 

1.4,12,5. Security 

One of the security concerns about phone transactions is the 
security of the phone system itself. Apart from the faiometric identification, 
the central problem is making sure that the number the individual called 
actually reaches the merchant in question. 

Note that the communications link between the PPT and the 
merchant isnt secured, so a purchase authorization from an individual to a 
merchant could be intercepted. However, no financial benefit would result 
from this, so it is not deemed to be important. 

The security of a PPT is relatively low by necessity of price, 
weight, and because of the problems inherent in splitting the responsibility 
of PIC entry and private code decryption and presentation. 
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1.4.13, Terminal: Cable-TV Point of Saie 

1.4.13.1. Purpose 

The purpose of the CATV point of sale terminal (CPT) is to 
authorize credit or debit financial traasactiom from an ^dividual in front of 
his television (or "TV") set to a merchant who is printing objects for saie 
on television. 

1.4.13.2, Construction 

The CPT consists of: 

• a BIA/catv 

• a television remote cannot with integrated BIA/catv 

• a Cable-TV digital signal decoder 

• a Cable-TV remote control reader 

• an on-screen display mechanism 

• access to a Cable-TV broadband two-way communications 
chanaei 

The CPT accepts faiometric identification using an BIA/catv that 
is integrated with the television's remote control device. The remote 
control communicates with a television top box that itself communicates 
with the broadband cable television network. The terminal consists of the 
television remote logic that communicates with the BIA, as well as the 
television top box that communicates over the cable broadband network. 

1.4.13,3. Identification 

In this transaction, the merchant and the individual must both be 
identified to execute the transaction. 

The individual is identified by the biometric-PIC. 

The merchant is identified by a merchant credential, created by 
the CATV broadcaster at the time the product is shown on television. 
Each product broadcast has a merchant-product credential consisting of a 
merchant code, a rime, a duration, and a once which is signed using Public 
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Key Encryption and the CATV network broadcaster's private key. This 
merchant-product credential can only be generated by tins network 
broadcaster. 

1-4.13.4. Operation 

As a television advertisement, an infornerciai, or a home 
shopping channel displays a product, the Cable television network also 
broadcasts simultaneous digital information that describes a short 
description, price, as well as the merchant-product credential. This digital 
information is processed and temporarily stored by the CPT, ready to be 
accessed by the individual when a decision to purchase is made. 

To buy something that is currently being displayed, the 
individual selects the on-screen display frnction of the special television 
Remote, which instructs the CPT to display text information on the screen 
regarding the currently viewed product. 

The individual is first prompted for the number of the items he 
wishes to buy through the on-screen display. Then he is prompted to enter 
his Biometric-PIC, and his account index code. Once he verifies that the 
final purchase price is okay, the product, price, merchant code, 
merchant-product credential, and channel number aiong with the 
Biometric-PIC are used to construct a Remote Transaction Authorization 
request message. The request is sent to the merchant for authorization by- 
way of the Cable-television broadband two-way communications channel. 

Note that each merchant that desires to sell products in this 
manner must have the ability to receive order information using the 
broadband Cable television network. 

Upon receipt of the authorization request, the merchant submits 
it to the DPC using a secured Internet connection or an X.25 connection. 

If the DPC authorizes the transaction, it constructs an 
authorization response that includes the current mailing address of the 
individual in addition to the authorization code, and the encrypted private 
code. Once the merchant receives the authorizarion, he copies the 
authorization and the mailing address, and then forwards the authorization 
back to the CPT, who men displays the private code to the individual, 
terminating the transaction. 
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1.413,5. Security 



This architecture does not aliow criminals to repiav messages 
intercepted from the CableTV broadband, but they are able to read parts of 
them. If this is not desirable, then the messages may be encrypted using an 
optional CATV Center's public key, or other "link level" encryption 
between the CATV set-top box (known k the industry) and the CATV 
local office. 

To secure a connection between a merchant and the DPC, the 
connection uses a session key changed daily that has been previously 
exchanged using a public key encryption key exchange system. 

L5, System Description: Data Processing Center 

1.5.1, Introduction 



The Data Processing Center (DPC) handles financial transaction 
authorizations and ^dividual registration as its mam responsibilities. In 
addition, the DPC provides storage and retrieval for secure faxes, 
electronic documents, and electronic signatures, 

Each DPC site is made up of a number of computers and 
databases connected together over a LAN (known in the industry) as 
illustrated in the DPC Overview Figure (number**). Multiple identical 
DPC sites ensure reliable service in the face of disaster or serious hardware 
Mure at any single DPC site. Furthermore, each DPC site has electrical 
power backup and multiple redundancy in all of its critical hardware and 
database systems. 

DPC components fall into three categories: hardware, software, 
and databases. Below is a short description, by category, of each 
component. More detailed descriptions appear in the following sections. 
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1.5.1*1. Hardware 

FW Firewall Machine: the entry point of the DPC site. 

GM Gateway Machine: the system coordinator and message 



DPCLAN DPC Local Area Network: connects the DPC sites 
1,5.1,2. Databases 

IBD Individual Biometric Database: identifies 

individuals from their biometric and PIC code. 

PFD Prior Fraud Database: lists individuals who have 
defrauded the system and can check if a biometric 
matches any of these individuals. 

VAD Valid Apparatus Database: stores information 
required to validate and decrypt BIA messages. 

AOD Apparatus Owner Database: stores information 
about the owners ofBIA devices. 

ID Issuer Database: identifies issuing banks that 
participate with the system. 

AID Authorized Individual Database: stores the list of 
individuals allowed to use personal or issuer BIA 
devices. 

SMD Remote Merchant Database: stores information 

necessary to process transactions with telephone and 
cable television merchants. 
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HDD Electronic Document Database: stores electronic 
documents, such as faxes and electronic mail, for 
retrieval by authorized individuals, 

BSD Electronic Signature Database: stores electrode 

document signatures for verification by a third party. 

1.5.L3. Software 

MPM Message Processing Module: handles the processing of each 
message by coordinating with the other software modules and 
databases required to perform the message's task. 

SNM Sequence Number Module: handles DUKPT sequence number 
processing. 

MACM Message Authentication Code Module: handles MAC 
validation and generation. 

Message Decrypt Module: handles encrypting and decrypting of 
BIA requests and responses. 

PIC Group List: bandies the lookup of PIC groups by PIC and 
the configuration of database elements that depend on the list of 
PIC groups. 

IBD Machine List: handles the lookup of the main and backup 
database machines dedicated to holding IBD records for a 
given PIC group. 



MDM 
PGL 

IML 
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1.5.1.4. Terminology 

When defining database schema, the following tenrinology is 
used for describing field types: 

iat<X> an integral type using <X> bytes of storage 

char<X> a character array of <X> bytes 

text a variable length character army 

<type>pq a length <X> array of the specified type, 

time a type used for storing time and date 

Mometric a binary data type used for storing the biometric 
a binary data type used for storing fex images 
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When describing database storage requirements, the term 
B expected- means the expected condition of a My loaded system. 

1.5J. Protocol Description 

TenoiaaJs accomplish their tasks by sending request packets to 
a DPC site. The DPC site sends back s reply packet containing the status 
on the success or failure of the request. 

Communication is via a logical or a physical connection- 
oriented message delivery mechanism such as X.25 connections, TCP/IP 
connections, or a telephone call to a modem bank. Each session holds the 
connection to the terminal open until the DPC sends its response back to 
the terminal. 

The request packet contains a BIA message pan and a terminal 
message part; 

BIA message part 

protocol version number 
message type 

4-byte BIA Identification 

4-byte sequence number 

<message specific data> 

Message Authentication Code (MAC) 
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Terminal message part 

<terminal specific data> 

The BIA message part is constructed by an BIA device. It 
includes one or two biometrics, a PIC, authorization amounts, and the 
contents of the general registers which are set by the terminal. Note: the 
MAC in the BIA message part only applies to the BIA part and not to the 
terminal part. 

A terminal may place additional data for the request message w 
the terminal message part. The BIA provides a message key to allow the 
terminal to secure the terminal part data. The BIA automatically includes 
the message key in the packet's encrypted biometric-PIC block when 
necessary. The terminal performs the message key encryption itself 
however. 

The response packet contains a standard header and two 
optional free-form message parts: one with a MAC and one without: 

Standard Header 

protocol version number 

message type 
Optional Free-form message pan with MAC 

<message specific data> 

MAC 

Optional Free-form message part without MAC 
'-additional message specific data> 

The message part with a MAC is sent to the BIA so that it may 
validate that this part of the response has not been tampered with and to 
display the mdlviduai's private code. The message part without a MAC is 
used ibr transmitting large amount s of data, such as fax images, that are 
not sent to the BIA for MAC validation as the BIA to terminal connection 
may be of limited bandwidth. 
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L5J. Processing Packets 

In an embodiment of the invention with multiple DPC sites, a 
teitninal need only send its request to one of the DPC sites, typically the 
closest, because that site automatically handles updating the others by 
running distributed transactions as necessary. 

When one of the DPC's Firewall Machines receives a packet, it 
forwards i t to one of the GM Machines for the actual processing. Each GM 
has a Message Processing Module that handles the coordination between 
the DPC components required to process the request and sends the 
response back to the sender, 

1.5.4. Vaiidatiag and Decrypting Packets 

AH packets the DPC receives, with the exception of those not 
constructed by an BIA, contain an BIA hardware identification code (the 
BIA Identification of the packet), a sequence number, and a Message 
Authentication Code (MAC). The GM asks the MAC Module to validate 
the packet's MAC and then checks the sequence number with the Sequence 
Number Module. If both check out, the GM passes the packet to the 
Message Decrypt Module for decryption. If any one of the checks fail, the 
GM logs a warning, terminates processing for the packet, and returns an 
error message to the BIA device. 

Currently, the only message types that are not constructed by an 
BIA is the Secure Fax Data request and Electronic Document Data 
request. 

1.5.5. Reply Packets 

Each packet the DPC receives may contain an optional response 
key stored in the encrypted biometric-PIC block of the packet. Before the 
DPC replies to a request that includes a response key, it encrypts the reply 
packet with the response key. It also generates a Message Authentication 
Code and appends it to the packet. 

The only exception to encrypting response packets applies to 
error messages. Errors are never encrypted and never include confidential 
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information. However, most response packets include a status or reply 
code that can indicate whether the request succeeded or not. For example, 
when the DPC declines a credit authorization, it does not return an error 
packet, it returns a normal transaction response packet with a reply code 



hS.6, DPC Procedures 

The DPC has two procedures commonly used while processing 

requests. 

1.5.6.1. Individual Identification Procedure 

For requests that require the DPC to identify an individual, the 
DPC executes the following procedure; using the PIC code, the DPC 
searches the IBD Machine List for the main and backup IBD machines 
responsible for handling identifications for the given PIC code. Next, the 
DPC sends the identification request to either the main or backup machines 
depending on which is the ieast loaded. The ffiD machine responds with 
the IBD record for the individual or an "individual not found" error. 

The IBD machine retrieves all the IBD records for the given 
PIC. Using a proprietary biometric hardware device, the IBD machine 
compares each record's primary biometric with the individual's biometric 
arriving at a comparison score indicating the similarity of the two 
biometrics. If no biometric has a close enough comparison score, the 
comparisons are repeated using the secondary biometrics. If none of the 
secondary biometrics have a close enough comparison score, then the JBD 
machine returns an "individual not found" error. Otherwise, the IBD 
machine returns the full IBD record of the individual, from which such 
fields such as the private code, account numbers, titles, and so on may be 
obtained. 

1.5-6.2. Emergency Response Procedure 

For requests that include an account index, the DPC handles the 
case where the individual chooses his or her emergency account index. The 
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GM processing the request immediately notifies the DPC customer support 
staff. Jogs a warning, and if the response packet has a reply code, sets it to 
"emergency". It is the responsibility of the owner of the BIA device that 
submitted the request to watch for an "emergency" reply code and provide 
further assistance, such as the false screen mechanism described in the 
ATM terminal section. The DPC also increments the emergency use coum 
of the individual's BD record whenever the emergency account index gets 
accessed, 

IS.7. Protocol Requests 

The following sections describe each protocoi request/response 
and the actions the DPC takes to perform them. 

The list of protocol packets are: 

* Individual Identification 

* Transaction Authorization 

* Registration 

» Account Access 

* Issuer Batch 

• Secure Fax Submit 

* Secure Fax Data 

* Secure Fax Tracking 

• Secure Fax Retrieve 

* Secure Fax Reject 

• Secure Fax Archive 

* Secure Fax Contract Accept 

♦ Secure Fax Contract Reject 

• Secure Fax Organization Change 

• Electronic Document Submit 

• Electronic Document Data 

♦ Electronic Document Tracking 

* Electronic Document Retrieve 

♦ Electronic Document Reject 

• Electronic Document Archive 
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• Eiectronic Document Archive Retrieve 

• Eiectronic Signature 

• Electronic Signature Verify 

• Network Credential 

L5J.1. Individual Identification 

Individual Identification Request 

BlAPart: 

4-byte BIA Identification 
4-byte sequence number 
emrypied0UKPTkey) Biometric-PIC Mack 

3Q0~byte authorization biometric 

4-12 digit PIC 

56-bit response key 

MAC 

Terminal Pari: (not used) 

Individual Identification Response 

encrypfed{re$pan$e key): 
private code text 
individual name 
biometric identification code 
MAC 

The Individual Identification request includes a biometric~PIC 
block which the DPC uses with the individual identification procedure to 
identify the individual. If the individual is identified, then the DPC 
responds with the individual's name, biometric identification, and private 
code. Otherwise, the DPC responds with an "unknown individual" error. 
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1.5,7,2. Transaction Authorization 



Transaction Authorisation Request 
BIA Part: 

4-byte BIA Identification 
4~byte sequence number 
encrypmd(DUKPTkey) Biometric-PIC Mock: 

300-byte authorisation Diametric 

4-12 digit PIC 

56-bit response key 

[optional 56-bit message key] 
account index 
price 

merchant Identification 

[optional free-format product Mormationj 

[optional merchant code (phone#, chsraiei# + time, hostname)] 

[optional send-address request] 

MAC 

Terminal Part: (not used) 



Transaction Authorization Response 
encrypied(response key): 
private code text 
authorization response 

authorization detail (autho code, transaction identification, etc) 
[optional individual address information! 
reply code {fail ok, emergency) 
MAC 

There are wo basic transaction authorization subtypes: retail 
and remote. 

For retail authorizations, the DPC identifies the purchasing 
individual by the biometric-FIC block of the request. If the individual 
cannoi be identified, the DPC replies with an "unknown individual" error. 

Next, the DPC sends an external authorization request 
(crediting the asset account of the BIA device's owner and debiting the 
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individual's asset account) to one of several existing financial authorization 
services depending on the type of asset accounts involved (such as Visa™ 
or American Express™). If the external financial authorization service 
approves the transaction, the DPC returns the external authorization codes 
and an "ok" reply code to the BIA device. Otherwise, the DPC returns the 
reason why the authorization was denied and sets the reply code to 
"failed". In either case, the DPC includes the individual's private code in 
the response. 

When the DPC looks up the individual's asset account using the 
account index of the request, the chosen account may be the "emergency" 
account. If this happens, the DPC follows the emergency response 
procedure. The external authorization still takes place, however. 

Remote authorization are generated by telephone, mail- order, 
or cable television merchants. The DPC handles remote authorizations the 
same way it does a retail authorization but with the following exceptions: 

i) Remote authorizations include a remote merchant code which 
the DPC checks against the Remote Merchant Database to validate 
whether the packet's merchant Identification matches the one stored in the 
database. Furthermore, the asset account credited is the remote merchant's 
account, not the account of the BIA device's owner. 

ii) Additionally, BIA devices that generate the remote 
authorizations tend to be personal BIA devices. The DPC checks the 
btometric Identification of the identified individual against the Authorized 
Individual Database's list of individuals allowed to use the BIA device. If 
the individual is not authorized to use the device, then the DPC denies the 
authorization request. 

iii) Finally, the authorization packet may contain a "send-address" 
indicator. This indicator informs the DPC to include the individual's address 
in the reply packet and is usually used only for mail order purchases. 

1 .5.7.3. Registration 

Registration Request 

BIA Part: 

4~byte BIA Identification 
4-byte sequence number 
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mcrypied{DUKPTkey) 3iomeMc~PIC block: 

1000-byte primary biometric 

1000-byte secondary biometric 

4-12 digit PIC 
56-bit response key 
5<S-bk message key 
MAC 
Termimi Part: 

mcrypiedfmessage key): 

name 

address 

zipcode 

private code 

asset account Est (account index code, account #) 
emergency account (account index code, account #) 
title list (title index code, title name) 

Registration Response 

status code 

emryptedfrespmse key): 
private code text 
PfC 

biometric Identification code 

list of DPC chosen PICs (if original choice of PIC 
is rejected) 
status code (ok, rejected) 
MAC 

Individuals register with the DPC via a Biometric Registration 
Terminal (BRT). The BRT sends the DPC a registration packet containing 
primary and secondary biometrics and personal identification code, along 
with ancillary data such as the individual's name, address, a list of financial 
asset accounts, the private code, and the emergency account. Optionally, 
the individual may include an electronic mail address, and a title list 
including titles and the title index code, as well as an Social Securiry 
Number (or "SSN"). The individual may choose his or her own PIC code 
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or allow the system to choose it. In a modification step any previously 
entered data can be modified or deleted. 

At any given moment, only one DPC site acts as the registration 
site, for implementation simplicity. Registration request packets received by 
non-registratiori DPC sites are forwarded to the current registration site. 
The registration DPC site performs the entire registration check, assigning 
of IBD records to IBD machines, and the distributed transaction required 
to update all other DPC sites. 

The registration DPC site selects the PIC code for registration 
requests that don't specify one, stores the IBD record on the main and 
backup IBD machines (as specified in the PIC Group List), and checks the 
PIC and biometric suitability of the registration packet before running the 
distributed transaction to update the other DPC sites. 

The DPC runs a personal identification code and biometric 
sample duplication check step wherein the biometrics and personal 
identification code gathered during the registration step is checked against 
ail previously registered biometrics currently associated with the identical 
personal identification code. The DPC may reject the registration for the 
following reasons: the PIC code is too popular, or the biometrics are too 
similar to other biometrics stored under the chosen PIC. To aid the 
individual in choosing an acceptable PIC, the DPC generat es a short list of 
PIC codes for which t he registration will be guaranteed that it reserves for 
a p eriod of time. The BRT then prompts the individual for a new PIC 
which may be chosen from the good PIC list. 

1.5.7.4. Account Access 

Account Access Request 

BMPart: 

4-byte BIA Identification 
4-byte sequence number 
eneryptedfDUKPTkey) Biometric-PIC block: 

300-byte authorization biometric 

4-12 digit PIC 

56-bit response key 

[optional 56-bit message key] 
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account index 
MAC 

Terminal Part: (not used) 

5 Account Access Response 

emrypiedfresponse key): 
private code text 
[optional PIC] 
asset account number 
10 reply code (fail, ok, emergency) 

MAC 

The account access request allows BIA-equipped Automated 
Teller Machines to provide a safer and more convenient way for individuals 
J5 to identify themselves to the ATM. 

The GM identifies the individual by the packet's oioraetrie-PIC 
and uses the specified account index to choose which asset account number 
to retrieve. 

When the GM looks up the individual's asset account using the 
20 account index of the request, the chosen account may be the "emergency* 

account. If this happens, the GM follows the emergency response 
procedure, 

1,5.7.5, Issuer Batch 

25 

Issuer Batch Request 

BIAPart: 

4-bvte BIA Identification 
4~byte sequence number 
30 mcrypiedfDtJKPTkey) Biameme-PIC block: 

300-byte authorization biometric 
4-12 digit PIC 
56-bit response key 
56~bit message key 
35 issuer code 

MAC 
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Terminal Part; 

encryptedfmessage key) batch list: 

add <biometric Id> <account index> <assei account [<emergency flag>] 
remove <biometric Id> <account index> <asset account> 

issuer Batch Response 

mcryptedfresponse key): 
private code text 
repiy code (fail ok, emergency) 
MAC 

encrypted/message key) failed list: 
failed <command> <code> 



The Issuer Batch request allows an issuing bank or other authority 
to perform routine maintenance on the Individual Biometric Database. The 
DPC logs a security violation warning if it receives any Issuer Batch requests 
from non-issuer BIA devices, and it also refuses to process the request. 

The DPC identifies the individual submitting the batch request by 
following the individual identification procedure. The DPC then checks that 
the individual is registered in the Authorized Individual Database to use the 
BIA device embedded in the sending issuer Terminal 

The DPC also uses the issuer code in the request to look up the 
apparatus owner Identification in the issuer Database and compare it against 
the apparatus owner Identification stored in the Valid Apparatus Database to 
ensure that the issuer code is not forged. 

The DPC then executes the add and delete commands in the 
message-key encrypted batch list. The batch list is a newiine separated list of 
commands. Valid commands are: 

add <biometnc Id> <accoum index> <asset accoum> [<emerg£ncy Qag>] 
remove <biometric Id> <account index> <asset account> 

The add command adds the asset account to the account list at the 
specified account index. The optional emergency flag indicates whether the 
particular account index is treated as the individual's emergency account, If the 
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asset account currently stored in the account list does not belong to the issuer, 
the command fails. This feature prevents one bank from adding or removing 
asset accounts from other bank's customers without the individual's knowledge 
or authorization. 

The remove command clears the individual's asset account stored at 
the specified account index in the account list. If the asset account currently 
stored in the account list does not match the account the issuer is attempting to 
remove, the command fails. 

For each command in the batch that failed to execute correctly, the 
GM logs a security violation warning and appends an entry to the failed list of 
the response. The failed entry includes the text for the command and the error 
code. 



1.5.7.6. Secure Fax Submit 

Secure Fax Submit Request 
BIA Part: 

4~byte BIA Identification 
4-byte sequence number 
enaypted0UKPTkey) Biometric~PlC Mock 
300-byte authorization biometric 
4-12 digit PIC 
56-4sit response key 
56-bit message key 
security mode (unsecured, sender-secured, secured, secured-confidentiai) 
sender title index code 
sender fax number 
sender fax extension 
recipient list 

[optional archive fax indicator] 
[optional contract/agreement indicator] 
Terminal Part: (not used) 
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Secure Fax Submit Response 

encryptedfrespowe key): 
private code text 
fax tracking number 
MAC 



When the DPC receives a Secure Fax Submit request, it identifies 
the individual from the request's biometric-PIC by following the ^dividual 
identification procedure. This identification, along with the mdividuai's title 
described by the title index code, is presented to the recipients so that the 
sender of the fax is always reliably identified. 

The DPC generates a tracking number for tracking purposes and stores it, 
the sender's biometric Identification, the security mode, and the message key in 
a newly created EDD Document record. For each recipient in the recipient list, 
the DPC also creates a Recipient record. The DPC then waits for the sending * 
fax machine to transmit the fax data encrypted under the message key. 

If the request includes an "archive fax*' or "contract/agreement « 
indicator, the EDD places a copy of the Document and Recipient records in the 
archive database. Any subsequent updates to these records are also made to 
the archived versions. 

The rax data is sent in a separate step so that if the sender makes a 
mistake entering his biometric and PIC, the system notifies him before he 
wastes any time feeding the document into the fax machke. 



1.5,7.7, Secure Fax Data 



Secure Fax Data Request 

B1A Part: (not used) 

Terminal Part: 

fax tracking number 
mcryptedfmessage key): 
fax image data 



Secure Fax Data Response 

status (incomplete, ok) 
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The Secure Fax Data request allows a secure fax machine to send 
the fax image to the DPC for delivery to the previously specified recipicnt(s). 
This request does not involve any biometric identification and instead relies 
upon the secret message key to securely transmit the image. 

The fax image data is encrypted by the message key registered by 
the Secure Fax Submit request, Once the DPC has received the entire fax, it 
sends a Secure Fax Arrival Notice message to each of the recipient's fax 
numbers. The DPC retrieves the list of recipients by querying the EDD for ail 
Recipient records containing the tax tracking number. The Recipient record 
contains the destination fax number and optional extension. After sending the 
Arrival Notice, the DPC updates each Recipient record's delivery status field to 
"notified". Note: if the destination fax number is busy, the DPC marks the 
delivery status 8eld to "busy" and retries sending the notice periodically (i.e., 
every 10 minutes) until successful and at that time, updates the status field to 



The Arrival Notice is as follows: 
Secure Fax Arrival Notice (Fax message) 

sender name, company, title, and rax number 
20 fax tracking number 

instructions on how to download the fax 



The DPC oniy sends the sender a Status Notice via fax after ail 
recipients have either retrieved or rejected the fax. The sender may query the 
DPC using the Secure Fax Tracking request (see below) to get the current 
status of all recipients. 



The Status Notice is as follows: 
Secure Fax Status Notice (Fax message) 

sender name, company, title, and fax number 
fax tracking number 
list of recipients showing: 

name, company, title, and fax number 
delivery date and status 
contract/agreement status 
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The DPC finds each individuals company and tide ixiformatioii in 
the EDD Organization table. 

For individuals who are not registered in the system and hence 
cannot receive secure faxes or for non-recipient secured modes, the DPC does 
not send them a Secure Fax Arrival Notice. Instead, the DPC sends them the 
fax directly. If the tax line is busy, the DPC retries every 10 minutes until it 
succeeds in delivering the fax. 

L5.7J, Secure Fax Tracking 

Secure Fax Tracking Request 
BIA Part: 

4-byte BIA Identification 
4-byte sequence number 
encrypted(DUKPTkey) Biomemc-PlC Mock: 

300-byte authorisation Mometric 

4-12 digit PIC 

56-bit response key 

56-bit message key 
fax tracking number 
MAC 

Terminal Part: (not used) 

Secure Fax Tracking Response 

mcrypmdfresponse key): 
private code text 
message digest for tracking response fax image 
status code (ok, failed) 
MAC 

fax image for recipient status list 

The DPC handles the Secure Fax Tracking request by retrieving ail 
EDD Recipient records for the fax and generating a fax message to display the 
records. If the individual making the tracking request is not the sender of the 
fax document, then the DPC sets the status code to failed and puts an empty 
fax in the response. 
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The tracking response fax contains information describing the status 
of the deliver)' of the fax to each recipient . This fex contains such status 
information as line busy, fex arrival notice sent, fax sent, fax rejected, contract 
accepted, and so on. 

The Tracking Notice is as follows: 
Secure Fax Tracking Notice (Fax message) 

sender name, company, title, and fax number 
fax tracking number 
list of recipients showing: 

name, company, tide, and fax number 
delivery date and status 
contract status 

1.5.7.9. Secure Fax Retrieve 

Secure Fax Retrieve Request 

SIAPart: 

4-byte BIA Identification 
4-byte sequence number 
encryptedfDUKPTkey) Biometric-PIC Mock: 

30O~byte authorization btometric 

4-12 digit PIC 

56-bit response key 
fax tracking number 
MAC 

Terminal Part: (not used) 

Secure Fax Retrieve Response 

encryptedfresponse key); 

private code 

56-bit message key 
status (incomplete, ok, invalid recipient) 
message digest for fax image 
MAC 

encryptedfmessage key): 

m 
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fax Image 

The DPC uses the biomerric-PIC to identify the individual making 
the retrieve request by following the individual identification procedure. If no 
EDD Recipient record exists for the individuai and for the specified fax, then 
the DPC responds with an "invalid recipient" status. 

The DPC retrieves the encrypted fax image from the EDD 
Document record with the correct fax tracking number and biometric 
Identification which it returns to the requester. 

The fax image includes a cover page that displays whether the fax is 
a contract/agreement and the sender's name, company, title, fax number, and 
extension. 

When the last recipient has either received or rejected the fax, the 
DPC sends a Status Notice via fax (see Secure Fax Data, above) to the fax's 
sender and then schedules to remove the Document and Recipient records 
from the EDD within a configurable time period. The time period is intended 
to aliow the recipients sufficient time to decide whether or not to archive the 
fax. 

1.5.7.10. Secure Fax Reject 

Secure Fax Reject Request 

BMPart: 

4-byte BIA Identification 
4-byte sequence number 
enctjptod(DUKPThey) Siomemc-PlC block: 

300-byte authorization biometric 

4-12 digit PIC 

56-bit response key 
fax tracking number 
MAC 

Terminal Part* (not used) 

Secure Fax Reject Response 

encrypted(respome key); 
private code 
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status code (ok, invalid recipient) 
MAC 

The DPC uses the biometrie-PIC to identify the individual making 
the secure fax reject request. The DPC finds the EDD Recipient record keyed 
by the request's fax tracking number and the individual's biometric 
Identification. If the record cannot be found then the request fails with an 
"invalid recipient" status. 

When the last recipient has either received or rejected the fax, the 
DPC sends a Status Notice via fax (see Secure Fax Data, above) to the fax's 
sender and then schedules to remove the Fax and Tracking records from the 
EDD within a configurable time period. The time period is intended to allow 
the recipients sufficient time to decide whether or not to archive the fax. 

1,5.7.11. Secure Fax Archive 

Secure Fax Archive Request 
B2A Port: 

4-fcyte BIA Identification 
4-byte sequence number 
emrypted&UKPTkey) Biometric-PIC Mock: 

300-byte authorization biometric 

4-12 digit PIC 

56-bit response key 
fax tracking number 
MAC 

Terminal Part: (not used) 

Secure Fax Archive Response 

encryptedfresponse key); 

private code 
status code (ok, invalid individual} 
MAC 

The DPC uses the biometrio-PIC to identify the individual making 
the secure fax archive request. The DPC finds the EDD Recipient record keyed 
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by the request's fax tracking number and the individual's .biometric 
Identification. If the record cannot be found and the individual is not the 
sender or one of the recipients, then the request Ms with an "invalid 
individual" status. Otherwise, the DPC copies the Document and Recipient 
records into the HDD archive database. Any subsequent changes to these 
records are also copied to the archived versions. 

hSJdl, Secure Fax Contract Accept 

Secure Fax Contract Accept Request 

B!A Part: 

4-byte BIA Identification 
4-fcyte sequence number 
encrypted(DUKPT key) Biomethc-PIC Mock: 

300-byte authorization biometric 

4-12 digit PIC 

56-bit response key 
fax tracking number 
MAC 

Terminal Part : (not used) 

Secure Fax Contract Accept Response 

mctypted(respan$e key): 

private code 
status code (ok, invalid recipient) 
MAC 

The DPC uses the btometric-PIC to identify the individual making 
the Contract Accept request. The DPC finds the EDD Recipient record keyed 
by the request's fax tracking number and the individual's biometric 
Identification. If the record cannot be found then the request fails with an 
"invalid recipient" status. Otherwise, the DPC updates the Recipient record's 
contract status field to "accepted" and generates a Status Notice to the fax's 
sender (see Fax Data, above). 
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